MTTR contains at least four distinct time components: time to detect, time to page, time to triage, and time to fix. Improving any one of them can move the aggregate. Optimizing the aggregate reliably improves none of them. That is the measurement trap I have seen in incident reviews: a team celebrates a lower MTTR while detection is slower, pages are noisier, triage is more confused, and the same engineers are being interrupted more often.
One number hides four different problems
Mean time to resolution sounds precise, but the clock usually starts and stops at points chosen by the team. In a typical incident, the elapsed time can be decomposed like this:
- Time to detect, or TTD: how long the system remains unhealthy before anyone or anything recognizes the problem.
- Time to page: how long it takes to route a signal to the person expected to respond.
- Time to triage: how long it takes to understand the failure mode and select a credible response.
- Time to fix: how long it takes to restore acceptable service after the response is known.
Different organizations use MTTR to mean mean time to recovery, repair, response, or resolution. Those are not interchangeable. A recovery metric may stop when service returns, while a resolution metric may stop after the root cause is addressed and follow-up work is complete. The label matters less than making the boundaries explicit.
Suppose a team reports an MTTR of 42 minutes. That number does not tell you whether detection took 25 minutes and the fix took 17, or whether detection took 2 minutes and a risky change took 40. Those incidents create very different customer impact and very different experiences for the on-call engineer. They also require very different improvements.
How optimizing MTTR creates the wrong incentives
Aggregates encourage teams to find the easiest way to move the line. That might mean closing incidents as soon as a rollback restores traffic, excluding long investigations from the incident system, or paging earlier without improving signal quality. Each choice can lower reported MTTR while leaving reliability unchanged.
Consider a team of six engineers managing a 90-day on-call rotation. At the start of the quarter, their median incident duration is 38 minutes and their p95 is 3 hours. They invest in a faster rollback command and become disciplined about declaring recovery as soon as the error rate falls. The next quarter, mean MTTR drops to 24 minutes.
On paper, the team improved by 43 percent. In practice, the rollback only addresses the visible symptom. Follow-up investigations are opened as separate tickets, so the measured incident ends before the cause is understood. The p95 duration is still close to 3 hours. Meanwhile, the team adds a lower threshold to its alerting rules. TTD and time to page improve for some incidents, but the on-call interrupt rate rises from 4 to 11 pages per shift, with many alerts requiring no action.
The aggregate improved while the on-call experience deteriorated. Engineers now wake up more often, spend less time asleep between pages, and still need to investigate recurring failures during business hours. If you looked only at MTTR, you would likely approve the changes again.
This is not an argument against measuring recovery time. It is an argument against treating one average as the objective function for incident response. The metric can be correct and still be insufficient.
Measure the clocks separately
The first practical change is to report the four time components independently. For each incident, record timestamps for the start of customer impact or system degradation, detection, page delivery, meaningful acknowledgement, diagnosis, mitigation, service recovery, and final resolution. You may not have perfect timestamps on day one. Approximate, consistently defined data is more useful than a polished aggregate with unclear boundaries.
Then inspect distributions rather than only means. Averages are heavily affected by a few long incidents and can conceal the experience of most responders. A useful view includes:
- TTD at p50 and p95, which shows both typical detection and the long tail of silent failures.
- Time to acknowledge and time to triage at p50 and p95, which separates notification problems from diagnosis problems.
- Time to recovery and time to final resolution, so mitigation is not confused with completed repair.
- Incident duration at p50, p95, and p99, particularly for customer-impacting incidents.
These slices point toward different actions. A high p95 TTD may call for better instrumentation, synthetic checks, or clearer SLO signals. A high time to page may indicate routing failures or an escalation policy that is too slow. A high triage time may point to missing runbooks, unclear ownership, or poor diagnostic context. A high fix time may reflect unsafe deployment practices, difficult rollback paths, or a system whose dependencies are not understood.
Do not combine those findings into a new composite score unless you have a clear operational reason. A dashboard with four understandable clocks is often more actionable than a single health index.
Add metrics for the cost of being on call
Incident response is not only a service restoration process. It is also a labor system. If your measurements omit the cost imposed on responders, you can improve response statistics by making the rotation harder to sustain.
Track on-call interrupt rate, separated by severity and by whether the page required human action. A page that wakes someone to approve a routine restart is not equivalent to a page for a data-loss risk. Track escalation rate as well. Frequent escalation can mean incidents are genuinely difficult, but it can also mean the first responder lacks the permissions, context, or automation needed to act.
Other useful questions include:
- What percentage of pages are acknowledged but never acted on?
- How many incidents require a second responder or a subject matter expert?
- How often does the same failure mode recur within 30 days?
- How many incidents are mitigated first and resolved later?
- What share of the error budget is consumed by incidents that were detected late?
Incident frequency belongs beside duration. A service with two 20-minute incidents may create less disruption than a service with twenty 5-minute incidents, especially if each event pages an engineer. The total number of pages, the hours spent responding, and the distribution of interruptions can reveal a reliability problem that MTTR misses entirely.
When MTTR is useful
MTTR is not useless. It is useful when the definition is stable, the population is clear, and the metric is paired with the context needed to interpret it. For example, a platform team can use median time to recovery for comparable, customer-impacting incidents to evaluate whether a rollback workflow is getting faster. A service owner can compare p95 recovery time before and after improving deployment safeguards. An organization can use MTTR as one input when checking whether an SLO process is reducing the duration of errors.
MTTR is also useful for detecting broad changes over time. If incident frequency, severity mix, and measurement boundaries remain reasonably consistent, a sustained change in MTTR deserves attention. The mistake is treating that change as proof that the whole response system improved.
Always segment the metric by severity, service, failure mode, and whether the incident was detected automatically or manually. Keep recovery and resolution distinct when the difference matters. A fast mitigation followed by a week of recurring symptoms is operationally different from a complete fix delivered in the same initial response.
A better operating question
The goal of measurement is not to produce a more impressive incident number. It is to find the next constraint in the system and reduce harm without transferring the cost to the on-call rotation.
Start with a small incident view that reports TTD, time to page, time to triage, and time to fix at p50 and p95. Add incident frequency, p95 incident duration, on-call interrupt rate, and escalation rate. Review the numbers together after each meaningful change to alerting, ownership, deployment, or automation.
Then ask a more useful question than "Did MTTR go down?" Ask: Which clock changed, what did responders experience, and did customer impact or recurrence improve with it?