Escalation policies

What is escalation?

Escalation is the process of notifying progressively broader groups of people when an alert is not acknowledged within a configured time. Without escalation, a single alert goes to a single channel and nothing more happens if it is missed. With escalation, missed alerts automatically notify the next person or team.

The workspace's On-call capability controls the available paging methods and the number of steps that may be added. The editor reports a capability limit when saving the next step would exceed it. Use pricing for current limits.

---

Escalation policy anatomy

An escalation policy is an ordered list of steps. Each step defines:

• Delay: delay_minutes: how long to wait after the previous step fired before this step fires. Delays are cumulative down the list. The first step's delay is honored too: a non-zero delay on step 1 means no one is paged until that many minutes after the incident opens.

• Notification target: exactly one target per step. Choose one of:

  Target	Who it reaches
  User	A specific person
  Notification channel	A configured channel (Slack, email, PagerDuty, …)
  On-call schedule	Whoever is on call on that schedule when the step fires
  Next / previous in rotation	The person after (or before) the current on-call on a schedule
  Team	The members (or admins) of a team
  Workspace owner	The account owner: a safety net
  Broadcast	Every enabled workspace channel at once

Example policy:

Step	Delay (after previous step)	Fires at	Target
1	0 min	T+0 (immediately)	Telegram to on-call engineer
2	5 min	T+5 min	Slack to team lead
3	10 min	T+15 min	Email to CTO + PagerDuty

Because each delay is measured from the previous step, the delays add up: with delays of 0, 5, and 10 minutes the steps fire at T+0, T+5, and T+15. Step 1 fires immediately here only because its delay is 0: if you set step 1's delay to 5 minutes, nobody is paged for the first 5 minutes after the incident opens, so keep the first step's delay at 0 unless you deliberately want that quiet period. Escalation stops advancing as soon as someone acknowledges.

Repeat

Repeat is a policy-level setting, not a per-step one. When enabled, after the last step fires without an acknowledgement the whole policy restarts from step 1, and it keeps cycling until someone acknowledges (or the alert resolves). The gap between cycles is the policy's repeat interval (defaults to 30 minutes): not the delay of step 1. Use it for critical policies that must nag until answered; leave it off to stop after the final step.

Alongside the policy steps, your personal notification chain runs in parallel and decides how you are reached. Each channel has a priority and a fallback_after_seconds delay, so a single page can fan out across channels over time, for example push now, email after 5 minutes, SMS after 10 minutes. The priority order and every fallback delay are configurable per channel.

---

Acknowledgement

Any team member can acknowledge an alert to stop the escalation chain from advancing. Acknowledgement methods:

• Dashboard: open the alert and click Acknowledge
• Telegram: tap the Acknowledge button in the alert message
• Discord: tap the Acknowledge button on the alert
• Slack: tap the Acknowledge button. It is available when Slack is connected through the OAuth "Add to Slack" installation (buttons on manually configured Slack incoming webhooks are inert).
• Email: click the Acknowledge link in the alert email
• Mobile app: acknowledge from the push notification or the app

Action	What happens
Acknowledge	Escalation stops advancing. The alert stays open and visible until the monitor recovers or someone closes it.
Silence (N minutes)	A pause. Escalation and your personal chain both hold, then both resume when the window ends.
Unacknowledge	Re-arms escalation and your personal chain immediately.

---

What happens after all steps complete

If every step fires and no one acknowledges:

• The escalation chain ends, no further notifications are sent.
• The alert remains open and visible in the dashboard.
• It will auto-resolve when the monitor recovers, or you can close it manually.

---

Selecting a policy for an alert

Policy selection follows one runtime order:

1. The first matching non-default routing rule wins. A rule can choose a policy or broadcast.
2. Without a matching rule, a monitor's escalation_policy_id is used when set.
3. Otherwise, the workspace default policy is used.

The current web app configures routing rules and the workspace default from On-call. API clients can set escalation_policy_id when creating or updating a monitor. If no rule, monitor policy, or workspace default resolves, no policy steps can run.

---

Maintenance windows

Active maintenance windows suppress all alerts and escalations for the selected monitors. If an alert opens during a maintenance window, the escalation chain does not start.

---