“Call everyone” is not an escalation policy.
When something breaks at 3am and the response is to page the whole team onto a bridge, that is not escalation. It is a panic broadcast. An incident escalation process is a designed system, and this is what happens when nobody designs it. The failure modes are predictable:
Why “Call Everyone” Fails
Diffusion of responsibility. If everyone owns the incident, no one drives it. People wait for someone else to move. Ten engineers on a bridge produce less progress than two engineers with clear ownership, because everyone assumes the person who knows this system best is already typing.
Alert fatigue. When the all-hands page is usually not for you, you learn to ignore it. And then you miss the one that was. Paging discipline is a budget: every unnecessary page spends attention you will need later.
No context transfer. Five engineers join the call all asking the same question: what is actually going on? The first fifteen minutes of the incident are spent narrating the incident instead of working it. Nothing was captured, so everything gets re-discovered live.
Senior burnout. Senior people end up answering pages a runbook should have caught. Every 3am wake-up for a known fault is a design failure billed to your most expensive and least replaceable engineers.
What a Real Incident Escalation Process Looks Like
Escalation is a designed system, not a reflex. Every company builds it differently, and the design is the difference between a fast resolution and a long one. Done badly, you end up with three or four layers all called “NOC,” each one reading the ticket aloud and passing it on, before the incident ever reaches someone who can actually fix it. That is not tiering. That is a relay race with no finish line.
Each tier exists because it adds a specific capability, not another body on the call.
Tier 1: The NOC
Triage against known patterns, run the runbook, capture diagnostic state before anything is restarted, and restore what is restorable. Most incidents end here, and that is the point of T1: not to escalate, but to resolve the known and document the unknown. The capture step matters more than most teams realize. Logs, routing tables, and interface counters taken before a reload are the raw material T2 works from. Skip it and the fault becomes unreproducible. This is the operating standard we hold our own 24/7 managed NOC services to, because a T1 that only forwards tickets is overhead, not a tier.
Tier 2: Network and Systems Engineering
Engaged when the fault does not match a runbook or exceeds T1’s authority, and engaged with the timeline and diagnostics already gathered, not from zero. T2 starts solving, not collecting. A clean handoff means T2’s first action is analysis, not an interview of whoever answered the first alert. Every fault T2 resolves should also produce a runbook update, so the same fault class lands in T1 territory next time. That feedback loop is how the known-pattern library grows and how the escalation rate falls quarter over quarter.
Tier 3: Architecture and Vendor TAC
Novel faults, design-level problems, and confirmed software bugs going to JTAC, Cisco TAC, Arista or Nokia support, with the evidence already packaged. A TAC case opened with full diagnostics attached gets an engineer assigned in hours. A TAC case opened with “router crashed, please advise” gets a request for the exact data T1 should have captured on day one, and the clock restarts.
How Many Tiers Does an Incident Escalation Process Need?
Three is not a magic number. It is the number that keeps showing up when the design is honest, because it maps to three genuinely different capabilities: pattern matching against the known, engineering analysis of the unknown, and design or vendor-level intervention.
Smaller operations sometimes run two tiers, with engineering and architecture merged. That works until the same two senior engineers become the destination for everything, which is the hero problem with a different name. Larger operations are tempted by four or five tiers, and that is almost always where the relay race begins. If you cannot state in one sentence what capability a tier adds that the tier below it lacks, the tier does not exist. It is a queue wearing a badge.
The test for any incident escalation process is not the org chart. It is the path a novel fault travels at 3am, counted in handoffs. Two handoffs from first alert to the person who can actually fix it is a design. Four is a bureaucracy that pages people.
The Rules Between the Tiers
What actually holds the incident escalation process together is not the tiers themselves, but the rules between them:
Time-based triggers. No progress in N minutes, escalate automatically. Do not wait for someone to feel bad enough to ask for help.
One incident owner at a time. Handoff is explicit. Ownership is never ambiguous, and never shared.
Page a rotation, not a hero. The engineer who always saves the day gets paged forever, until they leave.
Measuring Whether the Process Works
An escalation design that is not measured decays quietly. Four numbers tell you almost everything:
Resolution rate at Tier 1. The share of incidents that end where they started. Rising is good, and it should rise every quarter, because every T2 resolution is supposed to come back down as a runbook.
Time to escalate. Not time to resolve. How long a fault sat at a tier that could not fix it before moving. This is the number the time-based triggers exist to cap.
Context completeness at handoff. Crude but effective: did the receiving tier have to ask for data that should have been captured? Every such question is a gap in the capture runbook.
Repeat faults reaching Tier 2. The same fault class escalating twice means the feedback loop is broken. The incident was resolved. The incident escalation process was not updated.
The goal is not to pull in more people faster. It is to pull in the right capability at the right time, with the context already in hand. This connects to the biggest misconception about 24/7 NOC services: coverage is not the product, resolution is.
If your escalation path is a group chat and a prayer, you do not have one yet.
