Guide · alerting

The right person, and only them.

Alerting has three layers: channels (where messages go), alert plans (who is told, in what order, after how long) and on-call rotations (whose phone it is tonight). Each layer is optional — a single monitor with one email channel works, and so does a twelve-service fleet with rotations.

Channels

Connect once, reuse everywhere. Available channel types:

ChatSlack · Discord · Telegram · Microsoft Teams
PagingPagerDuty · SMS
PushPushover · ntfy
ObservabilityDatadog · Grafana · New Relic
WorkflowJira · Zapier · signed webhooks
ClassicEmail

Channels attach to monitors directly (this monitor → these channels) or through an alert plan. Webhook deliveries are signed — verification snippets live in the webhooks guide.

When an alert actually fires

A state change needs three consistent observations: the failed check itself plus the two instant parallel confirmation checks it triggers, so the confirmation arrives seconds after the first sighting — a 10-second monitor alerts in roughly 10–15 seconds of real time, and a single network blip never pages anyone. Monitors that flip repeatedly are flap-damped: recovery is only announced once the monitor has held stable. Paused monitors and active maintenance windows never alert.

Alert plans

A plan is an ordered list of steps: notify these channels, wait this long, and if the incident is still unacknowledged, move to the next step. Typical shape: push to the on-call person, SMS after five silent minutes, then the wider channel. Plans attach per monitor, and POST /escalation-policies/{id}/test fires a dry run so you can verify the wiring without breaking anything. Other tools call these escalation policies; the API does too.

On-call rotations

Rotations answer “who is on call right now” — members take turns on a schedule you define, holidays are handled with overrides (swap a specific stretch without editing the rotation), and GET /oncall-schedules/current returns the person of the moment, which is exactly what an alert plan step targets.

Recovery and the paper trail

Recovery notices go to the same channels that got the alert, and the incident closes automatically. Every alert becomes part of an incident timeline — acknowledgeable, commentable, attached to playbooks — see incidents & playbooks.

Via API

notification-channels · escalation-policies · oncall-schedules — each with Try-It panels. Alerts about your integration pipeline? Subscribe to webhooks instead of polling.