The Hidden Cost of Coordination Time in Incident Response

Ask any SRE what slows their team down during an incident. The answer is never "we could not figure out the fix." The answer is always some version of "we spent 20 minutes trying to figure out who was doing what." That is coordination time, and it is the single largest lever on your MTTR.

What is coordination time, and how much of MTTR is it?

Coordination time is any minute of an incident where no engineer is either diagnosing the problem or executing a fix. It is the setup, the discussion, the briefing, the status updates, the waiting for someone to join a call, the deciding who commands, the rewriting of a customer message three times.

Industry studies and internal audits at large engineering orgs consistently put coordination at 30 to 40% of total time-to-resolution. In practical terms, a two-hour incident includes 35 to 50 minutes of coordination overhead. That overhead is not free: it delays the fix, it delays the customer message, and it burns responders who came in to solve a problem.

Where does coordination time hide inside an incident?

Three places, roughly evenly split.

• Ack to declare. The pager fires at 14:02. Someone acks at 14:03. The incident channel does not exist until 14:11. During those eight minutes, one engineer is Slacking a manager to ask "do we declare this?" while the customer error rate climbs. This is the highest-leverage gap because it happens at the front of the incident when the blast radius is still growing.
• Role assignment and briefing. From channel creation to the first diagnostic action, another 5 to 15 minutes typically passes. The commander is being decided ("who has context on this service?"), the initial responder is briefing a second engineer, and the comms lead is being nominated by consensus rather than by rule.
• Status update tax. Once the fix is in progress, the debugger stops every 10 to 15 minutes to write a status update, or worse, is interrupted by three separate execs asking "what is the status?" Each interruption costs about 5 minutes of context recovery time.

Add them up on a real SEV2 and you get roughly 40 minutes of coordination on a two-hour incident. That number is remarkably consistent across teams.

Why do smart teams tolerate this cost?

Because coordination time is invisible in most dashboards. Your monitoring stack tells you time-to-detect and time-to-page. Your ticketing system tells you time-to-close. What sits in the middle, where the coordination happens, is a black box.

Ask an engineer what they were doing at minute 14 of the last incident and they will honestly answer "trying to figure out what was going on." Ask them what specifically they were doing, and the answer is often "reading the channel, waiting for someone to say who was in charge." That is coordination, but it does not feel like it, because the person felt busy.

Coordination cost is under-optimized because it is under-instrumented. Fix the instrumentation and the fixes become obvious.

How do you measure coordination time?

Instrument four timestamps per incident, in the timeline itself.

1. T0: alert fired. The monitor threshold breach.
2. T1: incident declared. The moment the channel exists and severity is assigned.
3. T2: first diagnostic action. The first log query, dashboard load, or command that was aimed at diagnosis rather than setup.
4. T3: resolution confirmed. Metrics recovered and stable for the confirmation window.

Then compute: - Setup overhead = T1 minus T0 - Handoff overhead = T2 minus T1 - Active work = T3 minus T2 - Coordination ratio = (setup + handoff) / (T3 minus T0)

Track the coordination ratio per incident. Watch it over 20 incidents. The teams with the lowest MTTR are almost never the teams with the fastest debuggers; they are the teams with the lowest coordination ratio.

What are the highest-leverage fixes for coordination cost?

Four fixes, in order of impact.

• Auto-declare from the monitor. If your paging tool already knows the severity of the alert, it should also create the channel, page the on-call, and post the initial context automatically. This collapses T1 minus T0 from 8 minutes to under 30 seconds.
• Pre-assign roles by rotation. The primary on-call is the commander by default. The secondary is the scribe. Do not decide roles per incident; decide them per week. This collapses T2 minus T1 from 10 minutes to under 3.
• Structured status updates. A single template ("status, next action, ETA to next update") that any responder can fill in without composing prose from scratch. Cuts the status-update tax from 5 minutes per update to under 60 seconds.
• Silence the peanut gallery. Executives and stakeholders subscribe to the status page or a broadcast channel, not the incident channel. The responders should not be answering "what is happening?" every 10 minutes during the fix.

The first two fixes together typically remove 12 to 20 minutes from every incident. That is a 15 to 25% cut in MTTR before anyone writes a line of code differently.

How much is coordination time actually costing you?

Do the math on your own team. Take your average SEV1 and SEV2 count per quarter and multiply by the estimated coordination time per incident. Then multiply by the industry-standard downtime cost estimate for mid-size and large companies, which is around $9,000 per minute in aggregate for a business at $50M to $500M in revenue.

A mid-size team running 8 SEV2s a quarter with 40 minutes of coordination overhead per incident is burning 5.3 hours of avoidable downtime per quarter. At $9,000 per minute, that is roughly $2.9M per quarter in exposure that never had to exist. Even if you discount the industry number by 80% for your specific business, you are still looking at $500K to $600K a quarter.

What does a low-coordination incident look like?

A monitor fires. A Slack channel appears within 30 seconds, with the on-call already tagged, severity auto-assigned, and initial context posted. The commander (already decided by rotation) confirms in one message. The debugger opens dashboards inside a minute. The comms lead posts the first status page update inside three minutes. Every 15 minutes, a structured status update goes out automatically from the timeline. The exec channel gets its updates from a broadcast, not from interrupting the debugger. The incident closes; the timeline is already complete; the postmortem draft is waiting.

Nothing about this requires more headcount, more heroics, or better engineers. It requires removing the manual coordination that used to happen and replacing it with structure.

The mistake to avoid

Teams try to reduce MTTR by making the fix faster: better dashboards, better observability, more junior engineers on-call. Those help at the margins. The bigger prize is coordination time, which is 30 to 40% of the total and much cheaper to compress. Measure it, name it, and remove it, and your MTTR falls without anyone getting smarter.