Notifications

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.

​

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.
• 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).

​

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

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.