Escalation Trees for When Everything Is on Fire

An escalation tree only proves it works the moment someone doesn't answer — and that's exactly the moment most teams discover theirs doesn't. A list of names in priority order isn't an escalation tree; it's a hope that the first person on the list is always awake, always has signal, and never has their phone on silent. A real escalation tree defines what happens automatically when that assumption fails: a timeout, a retry, a next name, and eventually a broader alert — with acknowledgement tracked at every step, not assumed.

Where escalation trees quietly fail

The gap is almost never in the primary on-call assignment — teams generally get that part right. It's in everything downstream of "the primary doesn't respond," because that path gets designed once, rarely tested, and then trusted for months or years without anyone confirming it still works.

No timeout, so escalation never triggers. If the tree pages one person and waits indefinitely for a manual decision to try someone else, you don't have escalation — you have a queue with one item in it. The incident sits unmanaged for however long it takes a human to notice the silence and manually intervene, which during a real incident can be the most expensive minutes of the whole event.

No acknowledgement tracking, so a delivered page looks the same as a seen page. An SMS or push notification that was successfully sent is not the same signal as a human confirming they saw it. Without acknowledgement tracking, "the page was delivered" and "nobody is actually working the incident yet" look identical from the outside, and the tree has no way to distinguish them and escalate accordingly.

Single-channel delivery, so one dependency takes out the whole path. Paging tools, the SMS carriers behind them, and the cloud infrastructure underneath both can share a failure domain you haven't mapped. If your paging provider and your primary production stack sit behind related infrastructure, an incident severe enough to need escalation can be severe enough to degrade the channel doing the escalating.

A trigger list nobody has reviewed since it was written. People change teams, leave the company, or rotate off on-call, and escalation trees are rarely on anyone's offboarding checklist. A tree that pages someone who left six months ago isn't a smaller version of a working tree — it's a broken one that hasn't been tested since it broke.

Designing a tree that actually reaches someone

Structure the tree around four elements, each addressing one of the failure modes above:

• A defined timeout per level. Set it based on how long your primary on-call actually takes to acknowledge a real page, not a round number chosen without data — then escalate automatically, without requiring a human to notice and intervene.
• Acknowledgement, not just delivery, as the signal that stops escalation. The tree should keep moving to the next level until a person confirms they've seen it, not until a message-sending API returns success.
• Delivery across channels that don't share a dependency. SMS, push, and email routed through genuinely separate providers give you a real fallback if one channel degrades — not three names for the same underlying pipe.
• A scheduled review of who's actually on the tree. Tie it to your existing on-call rotation process so the tree updates automatically as people rotate, rather than depending on someone remembering to edit a document.

Rehearsing it before the real thing

An escalation tree that has never been exercised is a plan, not a capability. Regulators in several sectors — DORA, FCA/PRA, APRA, MAS among them — increasingly expect documented evidence that incident response processes have actually been tested, not just written. A tabletop run that pages through the real tree in simulation mode, with no real notifications sent but a full audit trail of what a genuine run would have done, is the artifact that satisfies both the internal question ("would this actually work?") and the external one ("can you prove you tested it?").

How this fits a broader incident command surface

Escalation trees rarely operate alone — they're one piece of a larger incident lifecycle that includes playbooks, a shared war room, and a post-incident timeline, ideally on a surface that keeps working even if your primary tools are part of the outage. Glassbreak's incident manager capabilities cover per-team escalation chains with timeout and retry policy, multi-channel delivery, and acknowledgement tracking, alongside the playbooks and quorum break-glass access that typically sit next to escalation in a real incident. For the emergency-access piece specifically — the credentials an escalation eventually needs to reach — see break-glass account best practices. Teams that want to load their own escalation chain and run a tabletop before committing further can start for free with a single team.