An alert fires. Someone gets paged.
The clock starts.
That is how we think about incident response. The alert is the beginning. Resolution is the end. The time between them is MTTR. The metric everyone tracks, reports, and tries to reduce.
The problem is the clock starts at the wrong moment.
What happens when the alert fires is not resolution. It is not even the beginning of resolution.
What happens is the investigation.
Someone has to figure out what broke, why it broke, and what it connects to before anyone can fix anything. That work takes hours. And it runs entirely before the resolution process begins.
The resolution clock starts after the investigation ends.
Which means MTTR is not measuring what anyone thinks it is measuring.
Think about the actual sequence.
Alert fires. Someone gets paged. That person opens Jira. Pulls recent tickets. Checks GitHub. Finds the deploy. Cross-references the timestamp. Opens Salesforce. Reads the case. Translates a customer complaint written in plain language into something that points at a technical cause.
Two hours pass. Maybe three. The customer is still waiting.
Now the resolution begins.
MTTR captures what happens next. Not what happened first.
This matters because improvement efforts follow the metric.
If MTTR is the number you are trying to move, you work on the resolution phase. You improve your runbooks. You sharpen your escalation paths. You get faster at fixing things once you know what the thing is.
None of that touches the investigation. The investigation sits outside the frame.
So the hours your best engineers spend reconstructing timelines across four tools; before they can fix anything, before the resolution clock even starts; those hours are invisible in the metric you are using to measure your incident response.
You are optimizing the last mile. The first three are not on the map.
There is a version of this metric that would tell a different story.
Not time to resolution. Time to investigation start. Time in investigation. Time from investigation end to resolution.
Three numbers instead of one. Each pointing at a different place where the cost accumulates.
Your MTTR might be improving while your investigation time holds flat. Both can be true at the same time. You would not see it in the number you are tracking. The metric looks better. The cost does not.
Teams measuring MTTR and wondering why incident costs keep compounding are exactly who we’re thinking about.
If that’s your team, we offer a complimentary Investigation Cost Audit. Forty-five minutes. Structured diagnostic across five dimensions. You leave with a scorecard that quantifies what the investigation is actually costing you: in time, in recurrence, in the hours that never showed up in your MTTR.