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

# Notifications

> Route incidents to Slack, webhooks, email, and PagerDuty with a single routing model.

> The standalone Alerts page was retired. Routing is now configured under
> **Settings → Notifications** in the dashboard. The `/alerts` URL redirects
> there. The same idea, simpler shape: monitors detect, incidents coordinate,
> notification routes notify.

Squasher's notifications layer routes incidents to the channels your team
watches. You configure two things — destinations and routes — and one Slack
workspace can fan out to many channels.

Incidents can come from Squasher monitors, people, heartbeats, or inbound
[alert connectors](/integrations/alert-connectors). Alert sources let existing
monitoring systems raise, update, acknowledge, and resolve incidents; those
incidents use the same routes below.

## Concepts

* **Destination** — *where* a notification goes. One row per Slack channel,
  webhook URL, email recipient list, or PagerDuty service. Slack
  destinations link back to a connected Slack integration so a single OAuth
  install can power many channel destinations.
* **Route** — *when* a destination fires. A route holds a scope (which
  monitors, components, or incident sources it covers), conditions
  (attention tier, severities, lifecycle events, environments), and whether to include the AI
  incident summary. Each route fans out to one or more
  destinations through a many-to-many link.
* **Default route** — exactly one per project. Fires only when no
  non-default route matches. Useful for catch-all "send everything not
  otherwise routed to #engineering-alerts."

## Destination types

* **Slack** — `chat.postMessage` against the channel you pick after
  connecting Slack from **Settings → Integrations**. One Slack OAuth
  install can power many channel destinations. Each message includes a
  severity-colored sidebar, a `Severity / Status` pill row, and labeled
  `Impact / Root cause / Recommended action` sections sourced from the
  incident record. Opened incident cards also show recent deployment timing
  when Squasher can correlate the incident to a deployment from the previous
  hour. Long monitor URLs are auto-linked to keep the body compact.
* **Webhook** — JSON `POST` with optional HMAC SHA-256 signature
  (`X-Squasher-Signature` header) when you set a destination secret.
  Webhook destinations must use HTTPS. Private, reserved, loopback, and
  cloud-metadata address literals are rejected when the destination is saved.
  Before every delivery, Squasher resolves the hostname, rejects the delivery
  if any returned address is not public, and pins the TLS connection to a
  validated address. Redirects are not followed, and delivery attempts time
  out after 10 seconds. The payload includes a `severity` block — see the
  [Notifications API reference](/api-reference/alerts).
* **Email** — Resend transactional, up to 20 recipients per destination.
  The subject and body are prefixed with the incident's severity label
  (e.g. `[SEV-1]` or `[P1]` per project notation).
* **PagerDuty** — Events API v2. `dedup_key` = the incident id, so updates
  to the same incident reuse the PagerDuty incident; `event_action` is
  `trigger` on incident open, `acknowledge` on ack, `resolve` on resolved.
  The `payload.severity` enum is derived from the incident's severity rank
  (rank 1 → `critical`, 2 → `error`, 3 → `warning`, 4+ → `info`).

All four destination types render severity in the project's configured
notation — `SEV-1` / `SEV-2` / … by default, or `P1` / `P2` / … when the
project's `severity_naming_style` is set to `p` under
**Settings → Incidents**. Custom severity-level renames flow through the
same lookup, so a project that renames `sev-1` to `MAJOR` sees `MAJOR`
everywhere.

Native [on-call schedules](/features/on-call) can be used alongside
notifications. Agents should resolve current coverage first, then propose the
smallest route or escalation-policy change instead of paging arbitrary
destinations.

## Recommended setup

1. Connect Slack under **Integrations** when you want to notify a Slack channel.
   Webhook, email, and PagerDuty destinations do not require a separate OAuth connection.
2. Open **Settings → Notifications**, then create a destination pointing at the
   channel, HTTPS endpoint, recipient list, or PagerDuty service.
3. Create a default route with that destination + the lifecycle events you
   care about (usually `opened` and `resolved`).
4. Add severity-scoped routes when you want SEV-1 to also page PagerDuty
   while SEV-3 stays in Slack only.
5. Add a `digest` attention-tier route to a non-paging destination before
   applying an auto-tuning recommendation that demotes noisy monitor interruptions.
6. Use **Send test** on a destination to verify the path before relying on
   real incidents.

## Query monitor evaluation

* A query transport error or a missing non-count aggregate is recorded in the
  monitor's check history as an evaluation error or no-data result. It does not
  advance failure/recovery counters, change the monitor's last valid health, or
  open or resolve an incident. An observed count of `0` is still a valid signal.
* Web Vitals threshold monitors support exact `24h`, `7d`, and `30d` windows.
  Vitals spike monitors are not available until exact current and baseline
  ranges are supported.

## Delivery semantics

* An incident event fans out to every destination on every matching route.
  Specific routes take precedence over the default route: if any non-default
  route matches an incident, the default route does not fire for that event.
* Attention tiers are `interrupt` and `digest`. Monitor auto-tuning can apply
  an expiring `digest` override without changing the incident's factual
  severity. Routes may subscribe to either tier; omitting the filter matches
  both, preserving existing routing behavior.
* Lifecycle events are `opened`, `acknowledged`, `resolved`,
  `status_changed`, and `public_update`. Default routes usually subscribe to
  `opened` and `resolved`; add the other events only when those updates should
  page or post.
* Per-`(incident, event, destination)` dedupe — a successful delivery is
  never re-fired, even if a retry triggers later.
* Failed deliveries retry on exponential backoff (1m → 5m → terminal at
  attempt 3). Every attempt — success or fail — appears in the delivery
  history table at **Settings → Notifications → Delivery history**.
* Retry attempts preserve the route's AI-summary setting from the original
  attempt, even if the route is edited or deleted before the retry runs.
* Per-monitor cooldown (default 60 minutes) keeps a flapping monitor from
  filing a fresh incident every check; configure on the monitor itself.

## Agent handoff

Tell an agent to use notifications only after it has identified the project
and the destination/route to change:

```text theme={null}
Create or review Squasher notification routing for project <project_id>.
Start read-only by listing destinations, routes, and recent deliveries.
Propose the smallest change first, and ask before creating, updating, or
deleting any destination or route.
```

Use the [Notifications API reference](/api-reference/alerts), the
`@squasher-ai/api-client` `client.notifications` resource, or MCP
`search("notifications")` followed by `execute` for agent-driven setup.

For responder rotations, use [On-call](/features/on-call),
`squasher on-call current`, or MCP `search("onCall")`.