Your MTTR Is Mostly Waiting

Take your last ten severity-one incidents and split each clock into five parts. The repair is almost never the expensive one, which means most MTTR programmes are optimising the wrong thing.

An exercise you can run this afternoon

Pull your last ten severity-one incidents. For each one, split the total elapsed time into five buckets: detect, the gap between the fault occurring and anyone knowing; route, between knowing and the right person being engaged; investigate, between engagement and the cause being named; fix, the repair itself; and verify, confirming it worked and closing.

Then look at which bucket is largest. In most estates it is not the fourth one.

What the exercise usually shows

The pattern repeats with uncomfortable consistency. Detect and route together are frequently the majority of the clock. Investigate is second. Fix is often a rounding error.

We wrote up a scenario on this site of a core banking batch that stops at 23:52 and is discovered at 06:40 when a branch manager calls about missing statements. The repair, once the cause is understood, is applying a fallback rate and restarting from the failed step. Minutes. The night was nearly seven hours long.

That shape is not specific to banking. A disk that fills at 02:40 was filling for four days. A PON port that fails on day nine had been degrading since day one. A payment success rate that drops four points is found in a business dashboard that afternoon, not by any operational alert. In each case the repair was routine and the silence before it was not.

Why the industry optimises the wrong bucket

Almost every MTTR initiative targets fix. Better runbooks, faster deployment pipelines, more automation of the remediation step. Those are all worth doing, and they address the smallest number on the page.

Three reasons this keeps happening. The fix is the only bucket anyone instruments, because it is the only one with a clean start and end event. It is the bucket engineers control directly, so it is where improvement feels achievable. And it is what vendors sell, because automating a repair demos beautifully and automating a silence does not demo at all.

Meanwhile detect is invisible by construction. There is no event marking the moment nobody noticed something.

Detect is a monitoring design problem, not a tooling gap

The uncomfortable finding in most detect analyses is that the signal was present the entire time. It was present as a trend in a metric that nothing was watching as a trend.

Threshold monitoring answers one question: is this broken right now. It is genuinely good at that question. It is structurally incapable of answering the question that governs detect time, which is: is this on a path to being broken, and when.

A volume at sixty percent utilisation is not interesting. A volume at sixty percent that has been climbing steadily for four days, whose rate implies capacity is reached on Thursday, is a ticket. Same metric, same tooling, different question. Nobody had to buy anything to ask the second one.

Route is an ownership problem wearing a tooling costume

Route time is where escalation policies, on-call rotas and stale contact records live. It is also where the least engineering attention goes, because it does not feel technical.

The two failures we see most often are the same two every time. The alert reaches somebody who cannot act on it alone, so the clock continues while they find someone who can. And the contact record resolves to whoever raised the original change, who moved teams eighteen months ago.

What actually compresses the clock

Investigation that begins at the moment of failure rather than after a human has been located. That single change moves work out of detect and route and into a bucket that runs in parallel with nobody being awake.

Correlated rather than sequential investigation. A senior engineer checks the scheduler, then the host, then the upstream feed. Those three queries have no dependency on each other and running them together rather than in sequence is most of the investigate bucket.

Evidence arriving with the escalation. When a human is finally engaged, whether they receive an alert or a diagnosis with a proposed procedure and a blast radius attached decides whether their first twenty minutes are analysis or assembly.

Ownership resolved from current records. Not from the change ticket, not from a wiki page, from who owns the affected service today.

How to hold yourself to this

Instrument the five buckets and report them separately. A single MTTR figure hides exactly the information you need, because it lets a large detect time be offset by a fast repair and still look like an improvement.

Then set targets per bucket. If detect is sixty percent of your clock, a programme that halves fix time changes your MTTR by a few percent and consumes a quarter of engineering effort. The arithmetic makes the priority obvious, and almost nobody does the arithmetic.

Our own carrier deployment reports around fifty percent faster root cause and around sixty percent of recurring faults resolved end to end, measured in production and linked to the case study. Those numbers come from compressing detect and investigate, not from repairing faster.