A notification policy describes how an alert reaches a human. Policies match on severity and webhook source; each policy contains an ordered list of escalation steps; each step picks one or more channels (Slack DM, channel message, email, phone call, SMS) with an independent timer.
Channels
| Field | Type | Description |
|---|---|---|
Slack DM | channel | Direct message to the on-call engineer. Interactive buttons for acknowledge/escalate/resolve. |
Slack channel | channel | Posts to a configured channel. Useful for team-wide visibility on sev0/sev1. |
Email | channel | Templated email with the alert summary, metadata, and a direct link. |
Phone call | channel | Twilio voice call with TTS readout and DTMF acknowledgement. |
SMS | channel | Short text with the alert title and a link. |
Per-channel timing
Each escalation step runs its channels independently with their own delays. A common pattern for sev1:
- Step 1, immediate: Slack DM to primary on-call.
- Step 2, +2 minutes: phone call to primary on-call.
- Step 3, +5 minutes: phone call to backup, Slack channel post.
- Step 4, +10 minutes: email to engineering leadership.
Acknowledging the alert at any point halts the chain.
Severity matching
Policies declare which severities they handle. A typical setup has one aggressive policy for sev0/sev1 and a quieter one for sev2–sev4 that ends at Slack notifications without phone escalation.
Quiet hours and overrides
Notification policies respect per-user quiet hours for everything except sev0. Engineers can configure their own quiet windows from Account → Notifications; sev0 always pages because total outages are not a thing to sleep through.
Notifications are queued, not sent inline with the alert POST. That keeps the public API fast and lets the processor handle retries, backoff, and channel-specific failures (e.g. Twilio rate limits) without blocking your code.