---
title: Alerts
description: Rules that post to team chats and email subscribers about new errors, regressions, spikes and metric thresholds.
---

Alerts live under **Settings → Alerts**. Owners and admins create them with **New alert**; members see them read-only and choose which ones email them. Each alert watches one project, which can't be changed later.

## Kinds

| **When**         | Fires when                                                                        |
| ---------------- | --------------------------------------------------------------------------------- |
| **New error**    | An error group appears for the first time.                                        |
| **Regression**   | A resolved error group happens again.                                             |
| **Error spike**  | A single error group reaches the threshold of events within the window.           |
| **Error count**  | The number of error events in the window is above or below the threshold.         |
| **Failure rate** | The percentage of transactions that end with an error crosses the threshold.      |
| **P95 latency**  | The 95th percentile transaction duration, in milliseconds, crosses the threshold. |

## Condition

| Field                  | Kinds                | Values                                                                                                       |
| ---------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Environments**       | All                  | Only events from these environments count. Empty watches the whole project.                                  |
| **Threshold**          | Spike and metrics    | **Above** or **Below** for metrics. A whole number of events for a spike. 0 to 100 for failure rate.         |
| **Window**             | Spike and metrics    | 1, 5, 10, 15 or 30 minutes, or 1, 3 or 24 hours.                                                             |
| **Cooldown**           | All except New error | Shortest time between two notifications: none, 5, 15 or 30 minutes, or 1, 3 or 24 hours. Default 30 minutes. |
| **Notify on recovery** | Spike and metrics    | Sends a resolved message when the value is back to normal. On by default.                                    |

The environment list shows environments reported for the project in the last 30 days, except [hidden ones](/organization#environments).

## When notifications are sent

Spike and metric alerts are checked every minute over their window:

- When the value crosses the threshold, the alert sends a notification and shows **Firing**. It doesn't repeat while the value stays there.
- When the value is back, the alert returns to **Watching** and sends a resolved message if **Notify on recovery** is on.
- After a notification, it can't fire again until the cooldown has passed.
- An error spike tracks each error group on its own, so two groups fire and recover separately. Ignored error groups never spike.
- Failure rate and P95 latency need at least one transaction in the window. Without one, the alert keeps its state. Error count treats silence as 0, so a **Below** rule fires when errors stop.

New error and regression alerts send one notification per error group as it happens. A regression of the same group notifies again only after the cooldown. Each alert sends at most 30 of these an hour; the rest are dropped.

## Where notifications go

- **Team chats**: Slack channels, Discord channels and Telegram chats. Pick them per alert under **Team chats**.
- **Email**: each member chooses alerts under **Settings → Notifications → Alert emails**. The section switch turns all alert emails off. Creating an alert doesn't subscribe you.
- **Webhooks**: every alert also sends `alert.firing` and `alert.resolved` events to the organization's [webhooks](/webhooks).

Owners and admins connect chats under **Settings → Integrations** with **Add channel**. Slack and Discord ask you to pick a channel. Telegram opens the bot: pick the chat that should get alerts and add the bot. A provider marked **Not configured on this server** needs your operator to set it up ([Integrations](/self-hosting/integrations)).

A provider's page lists its channels and how many alerts use each. **Send test** posts a test message; **Disconnect** removes the chat from every alert.

## Status and actions

| Status       | Meaning                            |
| ------------ | ---------------------------------- |
| **Watching** | Enabled and not firing.            |
| **Firing**   | A spike or metric condition holds. |
| **Muted**    | Muted until a set time.            |
| **Disabled** | Turned off.                        |

Owners and admins manage an alert from its page:

- **Mute** for 1, 8 or 24 hours, or **Unmute**. Nothing is checked or sent while muted, and nothing is sent later.
- **Send test** sends a test notification to the alert's chats and email subscribers. Webhooks don't get it.
- **Disable** and **Enable** turn the alert off and on.
- **Delete alert** also deletes its notification history.

**Recent notifications** shows the last 20 notifications and each delivery: **Sending**, **Sent**, **Failed** or **Skipped**. Hover a failed delivery for the error. Temporary failures are retried, up to five attempts in all. **Skipped** means email isn't configured on the server.