Respond / PRODUCT GUIDE

Escalation policies

Define who to reach, which channels to use, and how response progresses.

Reviewed 2026-11-15Print-friendly guide ↗

Create a policy#

  1. Open Escalation Policies as an organization administrator and create an active policy.
  2. Add ordered steps with a delay, target type, and one or more channels.
  3. Choose a user, team, schedule, primary on-call, secondary on-call, or team-admin target as supported by the form.
  4. Configure repeats deliberately. Then assign the policy to an active service.
  5. Send a test event and check that the effective responder, timing, and channels match your intent.

Choose realistic targets#

A policy can be syntactically valid but operationally useless if the referenced schedule has no coverage, the target is inactive, or the responder lacks a usable destination. Channel preferences and provider configuration are separate from selecting a channel in a policy.

Durable execution#

Escalation jobs live in PostgreSQL and are claimed by workers. Worker restarts do not erase pending jobs. Acknowledgement or resolution cancels pending escalation work. Notification attempts are tracked separately, with bounded retries and visible failure outcomes.

Pause paging with a maintenance window#

Schedule a maintenance window from the Overview while a deployment or planned work runs. A window covers one service, or every service when an organization administrator creates it; team admins can schedule windows for services their team owns. A window lasts at most 14 days and must start within 90 days.

Incidents created during the window are recorded but not paged: they start acknowledged and snoozed until the window ends, and anything still open when it closes is paged then. Ending a window early releases its held incidents at once. Status pages that list an affected service show it as under maintenance while the window runs.

Delivery guarantees and limits#

Provider calls cannot participate in a database transaction. Notification attempts are at least once: a crash after a provider accepted a message but before success was recorded can cause another attempt. Stable identifiers help, but exactly-once handset delivery is not guaranteed. Provider acceptance is never proof of human response.

Find your next step.

Search runs locally. Nothing is sent to a search service.