> ## Documentation Index
> Fetch the complete documentation index at: https://sentrydocs.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Alerts
> Set up alerts to get notified when issues occur or metrics cross a threshold.
Sentry alerts notify you and your team when something goes wrong. You can create alerts that trigger based on issue activity or that monitor a metric over time and fire when it exceeds a threshold.
## Two types of alerts
Triggered by activity on an issue — when a new issue is created, an existing one regresses, or event frequency crosses a threshold. Best for reacting to specific error patterns.
Triggered when an aggregate metric (error rate, transaction duration, failure rate) crosses a threshold over a time window. Best for monitoring the overall health of a service.
## Issue alerts
Issue alerts fire when specific conditions are met on an issue. You define **conditions**, optionally add **filters**, and specify **actions** to take when the rule fires.
### Conditions
Conditions determine when the rule evaluates. Available conditions:
| Condition | Description |
| ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| **A new issue is created** | Fires the first time Sentry sees a new fingerprint |
| **The issue changes state from resolved to unresolved** | Fires on regressions |
| **An issue escalates** | Fires when Sentry detects a significant increase in event volume for an existing issue |
| **Sentry marks an existing issue as high priority** | Fires when an existing issue is escalated to high priority automatically |
| **The issue is seen more than {value} times in {interval}** | Fires when event count exceeds a threshold within a time window (1 minute to 30 days) |
| **The issue is seen by more than {value} users in {interval}** | Fires when unique user count exceeds a threshold |
| **The issue affects more than {value} percent of sessions in {interval}** | Fires when an issue impacts a percentage of total sessions |
Multiple conditions can be combined with **all** (AND) or **any** (OR) logic.
### Filters
Filters narrow down which issues the rule applies to, without changing when it triggers. Examples:
* Issue is assigned to a specific user or team
* Issue has a specific tag value (e.g. `browser:Chrome`)
* Issue level is error, warning, etc.
* Issue age is older or newer than a duration
* The event's attribute matches a value (e.g. `server_name` contains `prod`)
### Actions
When an alert fires, Sentry executes one or more actions:
| Action | Description |
| ------------------------------------------ | ----------------------------------------------------- |
| **Send an email** | Notify a member, team, or the issue's assignee/owner |
| **Send a Slack message** | Post to a Slack channel or DM |
| **Send a PagerDuty notification** | Page on-call via PagerDuty |
| **Send an OpsGenie alert** | Trigger an OpsGenie alert |
| **Send a notification via a webhook** | POST a JSON payload to a custom URL |
| **Create a ticket** | Open a ticket in Jira, GitHub Issues, or Azure DevOps |
| **Send a notification via an integration** | Route through a configured Sentry App |
### Creating an issue alert
Go to **Alerts** in the left sidebar, then click **Create Alert**.
Choose **Issues** when prompted to select between issue and metric alerts.
Choose one or more conditions that determine when the rule fires. Select whether all conditions must match or any single condition is sufficient.
Add filters to limit which issues trigger the alert.
Add one or more actions — email, Slack, PagerDuty, webhook, etc.
Give the rule a descriptive name, optionally assign an owner (team or member), and save.
## Metric alerts
Metric alerts monitor aggregate data over a rolling time window. Instead of reacting to a single issue, they watch your error rates, transaction performance, or crash-free session percentages.
### Alert thresholds
A metric alert has two optional threshold levels:
* **Critical** — fires when the metric crosses this threshold; highest severity
* **Warning** — fires at a lower threshold to give early warning before critical is reached
* **Resolved** — the alert returns to resolved state when the metric drops back below the threshold
### Time windows
Metric alerts evaluate data over a configurable window: 1 minute, 5 minutes, 10 minutes, 15 minutes, 30 minutes, 1 hour, 2 hours, 4 hours, 1 day, or 2 days.
### Creating a metric alert
Go to **Alerts** in the left sidebar, then click **Create Alert**.
Choose **Metrics** when prompted.
Select the metric to monitor: error count, error rate, transaction duration (p50, p75, p95, p99), failure rate, Apdex, or crash-free session/user rate.
Enter a critical threshold and optionally a warning threshold. Choose whether the alert fires when the value is above or below the threshold.
Add notification actions for both the critical and warning triggers.
Give the alert a name and save it.
## Alert status
| Status | Meaning |
| ------------ | --------------------------------------------------------- |
| **Critical** | The metric crossed the critical threshold |
| **Warning** | The metric crossed the warning threshold but not critical |
| **Resolved** | The metric returned below all thresholds |
Metric alerts require that your project is sending transactions or session data to Sentry. Error rate alerts work with error events only.
## Managing alerts
You can view all active and triggered alerts from the **Alerts** page. The alert history shows when each alert fired, how long it was active, and when it resolved. You can mute an alert rule to temporarily suppress notifications without deleting the rule.