What is actually inside that number

Take a typical incident. An alert fires. An engineer gets paged. They spend the first 15 to 25 minutes figuring out what is actually failing, what is connected to it, and where the fault originated. Then they fix it. Then they verify. Then they close the ticket.

The fix itself might take ten minutes. The verification another five. But the investigation beforehand took longer than both combined, and it all gets collapsed into a single MTTR figure that makes it look like recovery took 40 minutes when recovery actually took 15.

That distinction matters because investigation time and recovery time respond to completely different interventions. Better runbooks do not speed up investigation if the problem is that engineers cannot quickly map what is connected to the failing service. Faster rollback tooling does not help if the team is still spending 20 minutes figuring out what to roll back.

Mean time to diagnosis

The metric worth tracking alongside MTTR is mean time to diagnosis -- the time from alert to an engineer having an accurate picture of what is failing and why. It is harder to measure than MTTR but it tells you something MTTR does not: whether your problem is finding the incident or fixing it.

Teams that have invested in live dependency mapping consistently report that this number compresses first. Before they ship faster, before they write better runbooks, the investigation phase gets shorter because the system is already mapped when the alert fires.

Optimizing the right thing

If your MTTR has plateaued and you have already invested in runbooks, on-call tooling, and incident management process, it is worth asking how much of your remaining time is investigation versus remediation.

For most teams that have done that analysis, the answer is that investigation is still the bigger share. The tooling around fixing things has improved considerably over the last few years. The tooling around finding things has not kept pace. That is the gap MTTR is hiding.