Create and manage Metric Alerts by navigating to Alerts and clicking the "Alert Rules" tab, where you'll see a list of all active rules and can add new rules or modify existing ones. Then, select your project and choose Metric Alert.
The minimum role required to create alerts is member. Sentry users with manager or owner permissions can change the minimum role requirement in Settings > General Settings > Grant Members Alerts Write.
In the Alert Conditions section, choose between Errors or Transactions. Errors provide data around a break, such as new issues or total errors in your project. Transactions provide data on the performance of your application, such as latency and failure rate.
Errors and Transactions each have different metrics for alerting.
Choose the time period over which to evaluate your metric. Your choices range between one minute and one day.
Sentry evaluates the specified window each minute. For example, if you specify an hour time window, Sentry evaluates:
- 3:00pm: 2:00pm - 3:00pm
- 3:01pm: 2:01pm - 3:01pm
- 3:02pm: 2:02pm - 3:02pm
Specify which environment(s) will use this particular alert rule.
Environment is a Sentry supported tag that you can (and should) add to your SDK. Generally, the tag accepts any value but is targeted to refer to your code deployments' naming convention such as Development, Testing, Staging, or Production. The environment drop-down list is populated with the environment tag values available in your Event Stream.
Each environment typically necessitates different levels of urgency and workflow. The urgency and workflows you apply to Production alerts might differ from those you apply to alerts originating from your QA environment, for example.
Thresholds are numerical values that help define an alert trigger. The Warning trigger's threshold must be breached before the Critical trigger. Triggers are evaluated approximately every minute from the highest to lowest severity.
Actions define how you and your team will be alerted. Possible actions include:
- Send an email to a member or team. If sent to a member, the member's personal project alert opt-out settings are overridden.
- Send a Slack notification.
- Trigger a PagerDuty incident.
- Send a request to a webhook via internal integrations.
Manage your alert rule by giving it a descriptive name. A descriptive alert rule name specifies the team affected and the topic of the alert. For example, "Frontend Latency," "Backend Failure Rate," or "Billing Apdex."
Click "Save Rule".
The alert stream's default view shows unresolved alerts. Use auto-resolve (the default) in a metric alert if you mostly care about a sustained (not transient) change in your metric. For example, if there's an occasional latency spike in an endpoint caused by a single user, that's just noise. You can set the alert to auto-resolve.
On the other hand, if you get an alert for a spike in errors, that could indicate a real incident even if it subsides. You probably want the alert to stick around and show up in your default view. Therefore, you should unset the auto-resolve option.