Notifications
How channels, groups, and thresholds combine to decide who gets woken up.
Three things to wire up once per project:
Channel one delivery endpoint → Slack #backend-alerts
Group a named bundle of channels → "Backend on-call" = that Slack channel + an email
Monitor points at the group → Nightly backup → "Backend on-call"Channel one delivery endpoint → Slack #backend-alerts
Group a named bundle of channels → "Backend on-call" = that Slack channel + an email
Monitor points at the group → Nightly backup → "Backend on-call"A monitor with no group and no direct channel cannot page anyone. That is the single most common reason a working monitor produces silence.
Set it up in four steps#
- Open Settings → Notification Channels and connect one channel.
- Click Test on it. Confirm the message arrives before going further.
- Open Notification Groups, create a group, add the channel.
- Open the monitor's Notifications tab and assign the group.
Skipping step 2 is how teams end up discovering a broken channel during a real outage.
The eight channel types#
Every plan gets all eight. There is no channel gated behind a paid tier.
| Type | Best for | Connects by |
|---|---|---|
| Team-wide visibility, external recipients | Adding an address. External ones confirm first | |
| Slack | Channel-based team alerting | OAuth into your workspace |
| Microsoft Teams | Teams-based organisations | Pasting a webhook URL from the Workflows app |
| Telegram | Personal and group chats, forum topics | A bot connect flow |
| Discord | Community and dev-server alerting | OAuth into your server |
| PagerDuty | On-call rotations and escalation policies | An Events API v2 integration key |
| Browser push | Personal real-time alerts, no app install | One click per device |
| Webhook | Anything else that accepts inbound HTTP | A URL you control |
Channels has per-type setup. Webhooks has the exact payload.
How an alert travels#
Incidents are always recorded, even when paging is suppressed. The incident timeline is a factual outage record and does not depend on whether anyone was successfully paged.
Route to a group, or straight to a channel#
A monitor holds two lists: notification groups and direct notification channels. Both fire, and Drumbeats removes duplicates when a channel appears in more than one place.
Prefer groups. Fifty monitors pointing at one "Backend on-call" group means changing the rotation is one edit rather than fifty. Reach for a direct channel only for a one-off destination that no other monitor needs.
What an alert contains#
Every message carries the monitor name, the incident event (MISSED, FAILED, DURATION_HIGH, DURATION_LOW, or SSL_EXPIRING), the timestamp, and a deep link to the incident. Recovery messages add the outage duration.
What happens when a delivery fails#
A channel delivery fails when the destination returns an error, times out, or refuses the connection.
Drumbeats retries the delivery for about a minute, but only if every channel in the group failed. If even one channel succeeded, the failed channel is not retried and that alert never reaches it.
Browser push has extra failure modes that no retry can fix. Do Not Disturb and Focus modes suppress delivery at the operating system, and clearing browser data destroys the subscription. Keep a second channel on anything genuinely critical. Push troubleshooting covers each case.
Next#
Channels for per-type setup. Groups for routing patterns. Alert logic for the thresholds that decide whether a failure pages at all. Webhooks for the payload reference.