Alerts
Learn how to create and configure various alerts in Sentry to enhance the error and performance monitoring experience for you and your team.
Alerts provide real-time visibility into problems with your code and the impact on your users. There are several types of alerts available with customizable thresholds and integrations.
From the Alerts page in sentry.io, you can create new alert rules and manage existing ones. The “Alert Rules” tab displays your existing alert rules, along with their current status, project, team, and creation date. By default, the list is filtered so that only alerts associated with the teams you're a member of, as well as ones that aren't associated with any team, are displayed. You can change this using the filter button.
The Alerts page also displays a “History” tab where you can find a list of metric alerts with information like when it was triggered and how long it was active.
Issue alerts trigger whenever any issue in a project matches specified criteria. You can create alerts for issue-level changes, such as:
- New issues
- Issue frequency increasing
- Resolved and archived issues becoming unresolved
You can find a full list of issue alert triggers in Issue Alert Configuration.
Metric alerts trigger when a metric is breached for either error or transaction events. Use metric alerts to monitor a finite and known set of metrics and components you care about, such as error frequency or performance metrics in your entire project, on important pages, or with specific tags.
Create alerts to monitor metrics, such as:
- Total errors in your project
- Latency: min, max, average, percentile
- Failure rate
- Crash free session or user rate for monitoring release health
- Custom metrics
You can find a full list of available metric alerts in Metric Alerts.
Uptime alerts are triggered when an uptime HTTP check request fails to meet our uptime check criteria. You can use uptime alerts to make sure a specific URL is constantly available, even during periods of low or no traffic.
When you create a new project in sentry.io, you can select a default issue alert. However, you can also create your own alerts to suit your team’s needs, using these best practices as a guide.
Alerts should notify you when there's an important problem with your application. But they shouldn't be too noisy, because that can lead to alert fatigue. Muting alerts is one way to reduce noise, but we recommend following these best practices to help you create relevant alerts that notify the people equipped to fix the problem.
Any user can mute alerts for their entire organization by default, but users with manager or owner-level permissions can update the minimum role requirement by going to Settings > General Settings > Let Members Create and Edit Alerts.
Issue alerts can be muted on the Alerts details page by clicking the "Mute" button. This will keep the alert from notifying you until you click "Unmute". If you want to keep the alert from firing entirely, select "Mute for everyone" from the dropdown. If there's just one alert rule and it's set up to notify an entire integration, the only muting option will be "Mute for everyone". If there are multiple alert rules and they're set to notify both an integration and a user or a team, selecting "Mute for me" will only silence the alert for you, not the rest of the team.
Metric alerts work in the same way as Issue alerts and can be muted on the Alerts details page by clicking the "Mute" button.
Sentry has disabled duplicate alerts and alerts with no actions.
Anyone with alert edit access can re-enable an alert by editing its conditions and re-saving it. Alerts need to pass Sentry’s checks before they can be saved. See best practices for guidance on writing useful alerts.
Besides alerts, Sentry sends you notifications about various things like issue state changes, release deploys, and quota usage. You can fine tune these notifications, as well as your personal alert settings, in User Settings > Notifications. Learn more about notifications and adjusting their associated settings in the full documentation.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").