What Is an Escalation Policy and How Do You Build One That Works Under Pressure?

The page hits the primary at night. Their phone is on silent after a flight. Ten minutes pass. Twenty. The monitor is still red. In Slack, people start asking who owns payments. Someone DMs the engineering manager. Someone else pings the last person who touched the service. By the time a human with access is actually working the incident, customers have already been failing checkouts for half an hour.

That gap is not a heroism failure. It is a missing escalation policy.

What an escalation policy is

An escalation policy is the predefined sequence of contacts and wait times that determines who gets paged when the previous person does not respond in time. It is boring on purpose. The whole point is that nobody invents a paging order while the service is down.

Informal norms do not survive a real P1 overnight. "Message the team lead if you need help" is not a policy when the team lead is unreachable and three people are guessing in parallel. Undocumented escalation also creates blame afterward, because everyone remembers a different version of who should have been contacted.

Write it down. Configure it in the tool. Test that phones actually ring.

The components every policy needs

Primary responder

This is the engineer on the primary on-call rotation for that service. They get the first page. They are expected to acknowledge within the response window or the policy continues without waiting for a debate.

Response window

How long you wait before escalating. For P1, 5 to 10 minutes without acknowledgement is a common range. Shorter windows create more noise if people need a minute to get to a laptop. Longer windows quietly extend every outage. Pick a number, put it in the tool, and measure whether acks land inside it.

Secondary responder

Often a second engineer on a secondary rotation, or the on-call lead for the team. Their job is to take the incident when the primary does not ack, not to wait for a polite handoff that never comes.

Tertiary contact

Typically an engineering manager or service owner. They may not mitigate the database themselves. They can pull in the right people, declare severity, and unblock decisions when the first two tiers are stuck or unreachable.

Final escalation

For company-wide or revenue-critical incidents, define an executive or crisis contact. Most pages should never reach this tier. When they do, the policy should already have exhausted the technical response chain.

Notification channels at each tier

Push notifications are fine for the first attempt. Phone calls and SMS matter when people are asleep. A policy that only sends Slack messages to a channel is not an escalation policy. It is a hope.

How severity changes escalation

Severity should change speed and breadth, not invent a new social process each time.

P1. Short response window, phone calls early, secondary and tertiary ready to join fast.

P2. Slightly longer window. Overnight pages may wait for stronger confirmation, but still escalate if nobody acks.

P3. Business-hours routing is often enough. Escalation still exists for ignored pages during the day.

If everything escalates like a P1, people burn out and start ignoring the ladder. If nothing escalates like a P1, your worst nights stay quiet for too long. Tie windows and channels to severity definitions you already trust.

Override and absence handling

People get sick. People fly. People attend weddings. A policy that assumes the published primary is always reachable will fail the week someone is not.

Build an override path.

• The primary can hand off a window to a named substitute before the shift.
• If they cannot, the secondary becomes effective primary after the response window with no manual approval required.
• Keep phone numbers and notification tests current. An escalation to a disconnected number is theater.

Overrides should be normal, not a favor that requires political capital. If taking an override is painful, people will stay on the rotation while unreachable, which is worse for everyone.

Service-specific vs team-level escalation

A single company-wide ladder sounds simple and breaks as soon as two services have different owners. Payments may need the two backend engineers who know the ledger. The marketing site may escalate to a different pair.

Use team-level defaults for shared infrastructure, then attach service-specific policies where ownership is clear. The on-call schedule and the escalation policy should name the same services, or you will page the wrong rotation with perfect reliability.

Worked example. 15-person team, payments service

Assume fifteen engineers. Two backend engineers, Asha and Ben, own the payment service. Mei is the team lead. Ravi is the engineering manager. The team runs a weekly primary rotation among engineers who have completed shadow on-call for payments.

Payments P1 escalation

1. Primary on-call for payments. Push + phone. Ack window 7 minutes.
2. Secondary. The other payments-capable engineer on secondary rotation that week, or Asha/Ben if the primary is someone still ramping. Push + phone. Ack window 7 minutes.
3. Team lead Mei. Phone. She joins as incident coordinator if neither engineer has acked, or if they ask for help.
4. Engineering manager Ravi. Phone. Only if the incident is still unacked after the lead tier, or impact is company-wide.

Payments P3 escalation

1. Primary. Push only during business hours.
2. Secondary after 30 minutes without ack.
3. Stop before manager phone calls unless the issue is upgraded.

Configure overrides so Asha can hand Thursday night to Ben when she is traveling. Verify Mei's number in the tool before you need it. Walk through a test page quarterly.

Common mistakes

Escalating straight to the manager. Skipping a secondary technical tier burns managers and slows mitigation. Managers coordinate. They are not always the fastest restore path.

No response window defined. "Escalate if they do not answer" without a number means everyone waits a different amount of time.

Phone numbers never verified. The policy looks complete in a doc. The call goes nowhere.

Documented but not configured. A Notion page is not paging anyone. The tool must contain the same ladder.

One ladder for every service. Convenience during setup becomes confusion during the outage.

No link to the schedule. Escalation targets "whoever is on-call," but the schedule lives in a different product with a different source of truth. Keep them together.

Write the ladder before you need it

An escalation policy will not make incidents pleasant. It will keep a missed primary page from becoming an organizational scavenger hunt. Start with primary, window, secondary, and a verified phone path. Add tertiary and executive tiers when the blast radius justifies them.

If you want scheduling and escalation in the same workspace without per-responder fees, Vigiles handles that configuration as part of the incident workspace. The policy still has to reflect how your team actually owns services. The tool only enforces the ladder you were willing to write down.