The metrics that matter, and where they lie

Almost every team that starts measuring incident response reaches for the same two numbers first: how long it took to acknowledge that something was wrong, and how long it took to make it right. Mean time to acknowledge and mean time to resolve — MTTA and MTTR — have become the lingua franca of reliability reporting because they are intuitive, comparable, and easy to explain to someone who has never been on call. A leader who knows nothing else about your systems can understand "we used to take forty minutes to notice outages and now we take eight." That legibility is a real virtue, and it is why these metrics deserve a place in your practice. But legibility is also exactly what makes them dangerous: a number this easy to quote is a number people will quote without understanding, and a measurement nobody understands is one that will eventually be optimized in ways that make the underlying reality worse.

The first thing to be honest about is what each number actually contains. Time to acknowledge measures the gap between a problem becoming visible to your tooling and a human taking ownership of it. It is, at heart, a measure of your detection and routing pipeline — whether the alert fired, whether it reached someone awake and equipped to act, whether that person could tell it was real. A bad acknowledgment time is rarely a sign of lazy responders; far more often it is a sign that the page went to the wrong person, or competed with five noisy false alarms, or arrived as a notification nobody was positioned to see. Time to resolve, by contrast, spans the entire arc from detection to recovery, which means it is not really one measurement at all. It bundles together diagnosis, decision-making, coordination, the mechanical time to deploy a fix, and the time to confirm the fix worked. Two incidents with identical resolution times can have almost nothing in common: one was a thirty-second rollback discovered in twenty-nine minutes of confusion, the other a five-minute diagnosis followed by a genuinely hard twenty-five-minute repair. The number cannot tell them apart, and treating them as the same problem will lead you to fix the wrong one.

A mean is the wrong shape for incident data

The deepest flaw in MTTA and MTTR as they are usually reported is hiding in the first letter. Incident durations do not cluster around an average; they sprawl across orders of magnitude. Most incidents are short and shallow, a handful are catastrophic, and the distribution has a long, heavy tail. When you compute a mean over data shaped like that, a single eight-hour incident can drag your monthly average up by an amount that swamps the signal from a hundred routine ones. You end up reporting a number that no individual incident actually resembled — not the typical experience, not the worst case, just an arithmetic artifact of mixing the two. Worse, the mean is volatile in a way that invites misreading: one bad incident makes the metric spike, and someone asks why response got worse this month when nothing about your response changed at all.

The fix is to report the median instead, and ideally a high percentile alongside it. The median tells you what a typical incident looked like — half were faster, half were slower — and it barely moves when one outlier blows up. A percentile like the ninetieth or ninety-fifth tells you about the tail, the incidents that hurt the most, which is often where the real reliability story lives. A team whose median resolution is steady but whose tail is growing has a different problem than a team whose median is creeping up across the board, and only the distribution reveals which you are. Whenever someone hands you a single mean for incident duration, the right instinct is mild suspicion: ask to see the spread, because the spread is where the truth is.

Speed is a proxy, not the goal

Even read correctly, these metrics share a limitation that no statistical refinement can cure: they measure speed, and speed is only a proxy for what you actually care about, which is impact on the people who depend on the system. An incident resolved in four minutes that corrupted a thousand records is worse than one resolved in forty that inconvenienced nobody. A fast acknowledgment that led to a panicked, destructive "fix" is not a success just because the clock looked good. When speed becomes the explicit target, teams find ways to make the clock happy that have nothing to do with serving users: closing incidents prematurely and reopening them quietly, declining to declare incidents at all so they never enter the denominator, acknowledging instantly to stop the timer and only then beginning to think. Every one of these makes the metric improve while the actual practice rots. This is not a hypothetical failure mode; it is the predictable result of pointing a target at a proxy, and it is the single most common way insight programs poison themselves.

The way to keep speed honest is to hold it next to severity. A resolution time is meaningful only in the context of how bad the incident was, so segment your metrics by severity rather than averaging across all of them. A creeping median for your most serious incidents is an alarm worth sounding; the same movement among trivial ones may be noise, or may even be healthy if it means you are now declaring smaller things that you used to ignore. Looking at speed and severity together also guards against the quietest distortion of all — that simply by measuring incidents more carefully, you change which events get counted, and a metric can move purely because your definition of "incident" got better. That is a sign of a maturing practice, not a regression, and you will only recognize it as such if you are watching what goes into the number, not just the number itself.

None of this is an argument against measuring speed. Time to acknowledge and time to resolve are genuinely useful: they make response legible, they surface detection and routing problems you would otherwise feel only as vague frustration, and they give you a shared language for talking about whether things are getting better. The argument is only that they are instruments, not verdicts. Read as the median of a wide distribution, segmented by severity, understood as proxies for impact rather than substitutes for it, they earn their place at the top of your reporting. Read as a single average to be driven down at all costs, they will quietly teach your team to optimize the clock instead of the service. The metrics that matter are the same ones either way; the difference is entirely in whether you understand what they are telling you.