Designing an escalation policy

WHAT THIS TESTS Whether you can design an escalation policy that guarantees a critical alert is acknowledged and acted on, accounting for the human realities of missed pages and time zones.

A GOOD ANSWER COVERS The core mechanism is timeout-based escalation: the primary on-call is paged, and if they do not acknowledge within a defined window, the alert automatically escalates to a secondary on-call, then to a wider team or an engineering manager. This prevents a single missed page from becoming an unhandled outage. Configure multiple notification channels with escalating intrusiveness, for example a push notification, then SMS, then a phone call, so a sleeping engineer is reachable. Ensure coverage has no gaps: follow-the-sun rotations across regions or well-defined shift handoffs, with backups for vacation and overlap. Route by severity so only genuine Tier-1 incidents page humans while lower severities go to chat or tickets, protecting against fatigue. Define clear ownership, who is responsible, and a documented handoff so context is not lost. Consider acknowledgement and resolution SLAs appropriate to the tier, and integrate with the runbook and incident-management process.

COMMON WRONG ANSWERS A single on-call with no secondary or no automatic escalation, so a missed page means no response. No acknowledgement timeout. One notification channel only. Ignoring time-zone coverage and handoff gaps. Paging on all severities, causing fatigue.

LIKELY FOLLOW-UPS How long should the ack timeout be? How do you avoid escalation to people who cannot act? How does this tie into severity levels and SLAs?

ONE CONCRETE EXAMPLE For a Tier-1 payments service, a P1 alert pushes to the primary, escalates by SMS and a call if unacknowledged after five minutes, then to the secondary after ten, and to the EM after fifteen. Rotations follow the sun across three regions with a one-hour handoff overlap, and only P1 and P2 page, while P3 opens a ticket.