Escalation policies that actually escalate.
Multi-level chains with configurable timeouts. When the on-call doesn't respond, the next person gets paged automatically.
Build chains, not hope
Each level in the chain is a discrete configuration block. You set who gets paged (an individual or a role), how they get paged (Slack DM, email, or both), how long to wait before escalating, and what message they receive. The person at L2 knows they're L2. The page includes the original alert time, who was L1, and how long the timeout was. Per-service policies mean your checkout service can have a 5-minute L1 timeout with an aggressive path to the engineering lead, while your internal metrics dashboard sits at 30 minutes. Escalation urgency should match service criticality, not a single global setting applied everywhere.
The full escalation trail
Every page, every acknowledgement, every timeout is recorded on the incident timeline in sequence. You can see exactly when L1 was paged, when the 5-minute window closed, when L2 was paged, and who finally acknowledged. This isn't just useful for postmortems. It's the answer when someone asks why they got paged at 11:37 PM. The audit trail is permanent, attached to the incident, and included in postmortem exports.
Paging @sarah.chen (L1 on-call, Payments team)
No acknowledgement after 5 min. Escalating to L2.
Paging @mike.ross (L2 backup)
Works with your on-call schedule
Escalation policies are not static contact lists. L1 always resolves to whoever is currently on-call for the attached rotation, not a hardcoded name. When the weekly handoff happens and a new engineer picks up on-call, the escalation chain updates with it. If someone swaps a shift or sets a vacation override, the next page goes to the right person without anyone touching the escalation policy. The chain and the schedule are linked, not duplicated.
Frequently asked questions
Stop losing pages at 3 AM.
Free plan includes escalation policies. No credit card.