Route an alert to the right channel

Built for the gap between 'something broke' and 'the right person knows'

Most systems can detect a problem; fewer can decide, consistently, who should hear about it and through what channel without a human writing that logic into every single integration separately. notify.alert centralizes that decision — severity thresholds, on-call schedules, channel preference by alert type — so your monitoring, application code and third-party integrations all send alerts through one door instead of each hardcoding its own Slack webhook.

How routing and dedupe work together

POST /notify/alert takes an event with a source, severity and a dedupe key you choose — often a combination of the alert type and the affected resource. If an alert with the same dedupe key arrives again inside the configured window, it's folded into the existing alert instead of firing a second notification; once the window passes or the alert is acknowledged, the next occurrence starts fresh. Routing rules then decide the destination — Slack for warnings, a phone-reaching channel for critical severity, email for informational events — based on criteria you define once.

Alert fatigue is an old, well-documented problem

The pattern of teams silencing or ignoring alerts because too many low-value ones arrived alongside the important ones predates modern cloud monitoring by decades — it's the same failure mode that shows up in industrial control rooms and hospital equipment, which is part of why deduplication and severity-based routing became standard practice in incident management rather than a nice-to-have. We built this endpoint around that lesson instead of treating every alert as equally urgent by default.

Where it sits relative to the other notification endpoints

Think of this as the decision layer that sits in front of notify.slack, notify.discord, notify.webhook and notify.digest: your monitoring or application code sends everything here, and the routing configuration decides which of those channels actually fires for a given alert, or whether it should instead wait for the next digest. That keeps the routing logic in one place instead of duplicated across every service that can raise an alert.

What comes back to confirm it worked

You receive the routing decision made — which channel was used and why, plus whether the alert was new or deduplicated against an existing one — through a signed webhook or a signed link valid for 24 hours. If no rule matches an alert, that's reported explicitly rather than the alert quietly going nowhere, so gaps in your routing configuration surface immediately instead of during an actual incident.