Escalation

What an escalation policy does

Without escalation, an alert is sent once, to the channels attached to the monitor, and that is the end of it. With a policy, OKStatus keeps going until a human acknowledges the alert in the Alerts log.

t0 · alert +10 min +30 min +60 min NO ACK Level 1 Slack · email Level 2 PagerDuty Level 3 SMS on-call repeat 30 min ACK AT +6 MIN Level 1 ACK by Alice levels 2 and 3 never fire — Recovered still goes to the monitor's channels

Escalation policies live under Alerting → Escalation and are available on the Max and Enterprise plans.

Anatomy of a policy

Part	What it is
Name	“Production”, “Customer-facing”, “Night shift”…
Applies to	Which monitors the policy covers. The All monitors switch covers every monitor, including ones created later. Switch it off to target by tag, by group, or by picking specific monitors — the three add up.
Levels	An ordered list. Each level has a delay (immediately, or after N minutes / hours / days without acknowledgement) and one or more channels picked from the ones you already created.
Repeat	Optional: once the last level has fired, repeat it every N minutes until acknowledged.
Enabled	A disabled policy is kept but never runs.

A typical policy:

1. Immediately → Slack #ops and the on-call email.
2. After 10 min without acknowledgement → PagerDuty.
3. After 30 min → the engineering manager’s SMS, repeated every 30 min.

How levels resolve

• Only Down and Degraded alerts escalate. SSL and domain expiry warnings are sent once, to the monitor’s channels.
• Level 1 fires when the alert is raised. Channels that already received the alert because they are attached to the monitor are skipped, so nobody is paged twice for the same event.
• Every minute the engine checks each unacknowledged alert: has the next level’s delay elapsed? If yes, its channels are called and the log shows a Level N badge on the original alert.
• Acknowledging the alert stops the cascade immediately. Nothing after that moment fires. The Recovered notification still goes out through the monitor’s own channels, so the people who were paged know it is over.
• The cascade also stops on its own when the monitor recovers, is muted, or enters a maintenance window.
• If several policies match the same monitor (one by tag, one by group…), each of them runs its own cascade. Keep targets disjoint if that is not what you want.

What it is not (yet)

There are no on-call schedules or rotations: a level names channels, not people. Point a level at a channel that already does rotation for you (PagerDuty, Opsgenie, Grafana IRM, incident.io…), and let it own who is on duty.

Good habits

• Keep level 1 cheap and wide (chat + email), and put the paging channel at level 2. Most alerts are acknowledged before it fires.
• Give Repeat a value at least as long as your longest realistic response time — a 5-minute repeat on a 30-minute outage is 6 pages for one problem.
• Acknowledge from the Alerts log, not by muting the monitor: muting stops the cascade too, but it also silences every future alert.
• Test the whole chain once with a deliberately broken monitor, and read the Alerts log afterwards to see the levels stamped on it.