Escalation

The first thing an on-duty engineer hits at two in the morning, after an alert says payments are failing, is not a technical problem. Thirty minutes into the logs with no cause in sight, they have to decide alone whether it's acceptable to wake up their manager. Wake them for something that turns out to be minor and it's embarrassing; hold out and drag it to morning and the damage compounds. The real cost was that recovery stalled for exactly as long as the deliberation lasted.

So incidents kept growing the same way. The responder would work alone for two hours, and a colleague arriving at nine would name the cause in ten minutes. When someone asked in the morning meeting why nobody called, the answer was that it wasn't clear this counted as call-worthy. With no written threshold, neither side was wrong.

Escalation takes that judgment out of social calculation and turns it into a rule. Who gets called and when is decided before anything breaks, so when a condition is met, waking someone isn't a choice anyone makes — it's what the rule says happens. Once calling someone at 3 a.m. is keeping an agreement rather than making a personal decision, nobody hesitates.

The sequence has five steps: detection, first response, threshold check, handoff, and release.

1. Detection — the alert goes to one on-duty person. The clock starts the moment the event is judged an incident, meaning a problem that has actually affected the service.
2. First response — the responder acknowledges within an agreed window and starts narrowing the cause. Typically this covers saying "I've got it" within five minutes of the alert.
3. Threshold check — whether to hand off is decided by the clock and the blast radius, not by instinct. Pagedeck's rule is that failing to narrow the cause within 30 minutes, or affecting more than five customer accounts, triggers the next person without discussion.
4. Handoff — by phone. Typing someone's name into a chat channel is not a handoff. Any method a sleeping person can miss doesn't count as one. Three things travel with the handoff: what is happening now, what has already been tried, and what is being asked of the person receiving it.
5. Release — until the receiver says "I have it," the person who handed off stays on. Skip this step and you get a gap where both people assume the other is watching.

Which step the process starts at is set by severity, a grade assigned to how much a problem affects the service. When every user is unable to save, step 3 is skipped entirely and several people are paged at once.

There are three tiers of participants, and time plus blast radius decides when the tier changes.

1. Tier one is the on-call responder — the person who agreed to take incident calls for a defined period. Every alert starts here.
2. Tier two is whoever knows that area best. Payments failing means the engineer who built payments; a database problem means the person who has watched it longest. The 30-minute rule sends the incident here.
3. Tier three is whoever can make a decision. Whether to take the service down for a while, whether to notify customers before the fix lands — those don't get solved with engineering.

There is also a sideways call. If the accounts affected are covered by a service level agreement (SLA), the service level the company contractually promised a customer, sales or the account owner gets pulled in at the same moment. Recovering and notifying are separate jobs, and making the person recovering do both makes both of them late. The account owner usually knows what the customer was promised and how much notice they are owed, which is not something worth looking up mid-incident.

"We're past the 30-minute rule. Paging Theo."

The cause hasn't been narrowed, so tier two gets called per the rule. It also signals that nobody needs to feel bad about the page.

"It became clear this isn't something I can settle, so I went straight to Grace."

The situation called for a decision rather than engineering, so a tier was skipped.

"Haven't escalated yet — if I still can't narrow it in fifteen minutes, I will."

Reporting the current state and the next action in the same breath.

At Pagedeck, document saves once started failing intermittently on a Friday evening. The responder narrowed the cause to the storage service within fifteen minutes but still had no explanation after thirty. The rule woke Theo, who found the cause twenty minutes later. Meanwhile Sofia notified the three customer accounts the company was contractually obliged to inform.

After recovery, Mia went back and questioned whether thirty was the right number. It isn't a fixed value — it comes out of the record of incidents the team has actually had. If four of the last six causes were found within twenty minutes, the threshold can move to twenty; if every one of them took forty-five, a 30-minute rule is just a rule for waking people up early.

The most common reading is that escalating is a report of failure. Calling in someone else sounds like an admission of not solving it, which makes the assumption a natural one. But what the procedure measures is time, not skill. Thirty minutes is a length anyone can hit, and the rule is a promise that past that point nobody gets left alone. On a team that treats paging as a black mark, responders start pushing past the threshold and holding out, and every incident runs longer than it needed to. The number that suffers is not any one person's record but the team's recovery time.

The other one is treating a handoff as the end of your involvement. Ordinary work handoffs behave that way, so the same picture gets applied. In practice the original responder stays attached until the receiver confirms, and afterward remains the person who holds the context of everything already tried. On teams that drop the moment they pass it along, there's a ten-minute window where neither person is watching the screen, and those ten minutes land directly in mean time to recovery (MTTR), the average time from the start of an incident to its recovery.