> ## Documentation Index
> Fetch the complete documentation index at: https://docs.use.observer/llms.txt
> Use this file to discover all available pages before exploring further.

# Notifications overview

> Route incident alerts to chat, on-call, and webhook destinations from the Alerts page.

Alerts notify your team about incidents, maintenance, metric status changes,
SLO burns, and agent health on your status pages. They are configured by the page owner, not by public
subscribers: visitors subscribe on the status page itself, by email, Slack,
Microsoft Teams, or webhook. See
[Subscribe to a status page](https://docs.use.observer/docs/guides/status-page-subscriptions.md).

## How it works

When an incident is published, updated, or resolved, Observer fans the event
out to every enabled destination that matches the affected page. Metric, SLO,
and agent events are routed the same way. Each destination chooses which alerts
it receives, with optional routing filters, a snooze, and a daily digest. Each
destination formats the event for its channel (a Slack message, a
PagerDuty trigger, a signed webhook) and delivers it. Deliveries retry on
transient failures and record a result you can inspect.

The agent never sees these destinations. Routing happens in the control plane
from the precomputed incident state, so a webhook URL or API key you store
here is never handed to an agent.

## How alerts open and close

On-call destinations (PagerDuty, Jira, Splunk On-Call, Grafana IRM) open
one alert per subject and close it when the subject recovers:

| Subject | Opens on | Closes on |
| - | - | - |
| Incident | Published (updates attach to it) | Resolved |
| Metric | Unhealthy, degraded or no data | Recovered, or alert closed (deleted, paused, monitoring changed, agent removed, removed from page) |
| SLO | Burn started | Burn resolved |
| Agent | Offline, lagging, uptime degraded | Cleared |

* **What opened always closes.** A close is sent only to destinations that received the alert, and filters, snooze and page binding never block it.
* **Nothing closes that never opened.** You won't get "recovered" for an alert that wasn't sent to you.
* **Still true after a pause?** When a snooze ends or monitoring resumes and the metric is still failing, the alert is sent again, saying why.
* Scheduled maintenance notices, SLA statement notices and the daily digest are informational: they never open an on-call alert.

## Scope

Every destination is either:

* **Org-wide**: fires for incidents on any page in the organization.
* **Page-scoped**: fires only for incidents and metrics on one status page.

Set the scope with **Routing** > **Status page** when you add the destination:
**All status pages (organization-wide)** or one page. Agent health, SLO, and
SLA Ledger alerts are delivered only to org-wide destinations.

## Channels

> [card] [Chat and webhooks](https://docs.use.observer/docs/notifications/chat-and-webhooks.md)
>
> Slack, Discord, Microsoft Teams, a generic signed webhook, and email.

> [card] [Telegram](https://docs.use.observer/docs/notifications/telegram.md)
>
> Connect a Telegram chat with a one-click deep link.

> [card] [PagerDuty](https://docs.use.observer/docs/notifications/pagerduty.md)
>
> Trigger, update, and resolve a PagerDuty incident. Agent, metric, and SLO
> alerts also open and resolve their own on-call incident.

> [card] [Jira](https://docs.use.observer/docs/notifications/jira.md)
>
> Open a Jira issue per incident and transition it on resolve.

> [card] [Splunk On-Call](https://docs.use.observer/docs/notifications/splunk-on-call.md)
>
> Open and recover a Splunk On-Call incident.

> [card] [Grafana IRM](https://docs.use.observer/docs/notifications/grafana-irm.md)
>
> Fire and resolve a Grafana IRM alert via an incoming webhook.

> [card] [RSS and Atom feeds](https://docs.use.observer/docs/notifications/rss-feeds.md)
>
> A public feed of incidents per status page. No setup.

## Add a destination

1. Open **Alerts** in the console.
2. Choose **Add destination** and pick a channel under **Channel**.
3. Under **Connection**, enter the connection details (a webhook URL, an API
   key, a chat id). **Send test** sends one sample message without saving.
4. Under **Alerts**, pick a preset (**Paging**, **Everything, daily digest**)
   or **Custom** to choose alerts yourself.
5. Under **Routing**, choose **All status pages (organization-wide)** or one
   page, and optionally narrow by services, metrics, and minimum severity.
6. Select **Add destination** to save. **Send test** is also in the row's
   actions menu on the **Alerts** page.

> [!NOTE]
>
> **Secrets are encrypted at rest**
>
> Webhook URLs, routing keys, and API keys are encrypted before they are stored.
> After you save, the value is shown masked and never returned in full. To change
> a secret, type a new value over the mask; leave it masked to keep the current
> one.

## Delivery results

**Latest alerts**, at the top of the **Alerts** page, lists recent deliveries
with their outcome (delivered, retrying, failed, or skipped), the destination,
the event, and when it happened.
Use it to confirm an alert reached its destination or to see why one did not.

## Plan availability

Alerts require a paid plan. The number of enabled destinations and daily
deliveries is set by your plan.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.