Mean time to resolution

At a glance

Metric	Clock starts	Clock stops	What it really tells you
Mean time to detect (MTTD)	The failure begins	Something notices	Whether your monitoring covers reality
Mean time to acknowledge (MTTA)	The page is sent	A human takes it	Whether the rota and escalation work
Mean time to resolution (MTTR)	The incident begins	Service is restored	The whole response, dominated by diagnosis
Mean time to repair	The incident begins	The fix is applied	Similar to MTTR, sometimes excluding verification
Mean time between failures (MTBF)	Service restored	The next failure	How often you are in this situation at all
Time to permanent fix	The incident begins	The underlying cause is removed	How much of your resolution was a workaround

How it works

Mean time to resolution is an average of elapsed times across a set of incidents. The arithmetic is trivial and every difficulty is in the definitions underneath it.

The start of the clock is the first disagreement. Some teams start when the failure actually began, reconstructed afterwards from telemetry, which is the honest measure of customer impact. Others start when an alert fired, which excludes however long the problem ran undetected. Others start when a human acknowledged. The gap between the first and the third can be hours, and the choice can move a reported MTTR by a factor of two without anything about the response changing.

The stop is the second. Service restored is the common answer, and it usually means the symptom is gone rather than the cause. A rollback restores service in four minutes and leaves the underlying defect entirely in place. If your MTTR stops at restoration, and most do, then it is measuring how fast you can make the pain stop, not how fast you understand your system.

Which incidents count is the third and the most consequential. An organisation that opens an incident record for every noisy alert accumulates a large population of trivial, quickly-closed events that pull the average down. One that reserves incidents for customer-facing outages has a smaller, harsher population. Both are defensible and their MTTRs are not comparable.

The mean itself is the fourth problem. Incident durations are heavily skewed, with most short and a few very long, so an average is dragged around by the tail. A median plus a 90th percentile describes the distribution far better, and teams that switch usually discover their real problem was always the tail.

How it is measured

Fix the definition first and write it down where the number is published. A dashboard showing 42 minutes without saying what started and stopped the clock cannot be compared with anything, including its own value last quarter.

Take timestamps from systems rather than from people. Detection time from the monitoring platform, acknowledgement from the paging tool, restoration from the signal that recovered rather than from someone declaring it over in a channel. Human-entered times drift towards whatever makes the report look reasonable, without anyone intending it.

Report the distribution, not just the average. Median, 90th percentile and count, segmented by severity, tells you something actionable. A single mean across all severities tells you almost nothing, because a change in the mix of incident types moves it more than any improvement in response does.

Then decompose it, because MTTR as one number is not actionable. Split the elapsed time into detection, acknowledgement, diagnosis and remediation. Almost every team that does this for the first time finds diagnosis is the largest share by a wide margin, which redirects effort away from paging tools and towards understanding what changed. How teams actually reduce MTTR covers what follows from that finding.

Common misconceptions

That a lower MTTR is always better. It can fall because you got faster, or because you started opening incidents for trivial alerts, or because more responses are now rollbacks that leave the cause in place. The number alone does not say which of the three happened.

That MTTR is comparable across organisations. It is not, because the denominator is unstandardised. Published industry benchmarks compare populations defined differently, and a team measuring itself against one is measuring against an artefact.

That MTTR measures the fix. In most implementations it stops at service restoration, so a workaround counts as a resolution. Tracking time to permanent fix separately is what exposes how much of your reliability is held together by mitigation.

That faster paging is the lever. Acknowledgement is usually minutes and diagnosis is usually much longer, so halving MTTA barely moves MTTR. How root cause analysis works and how it is measured covers the part that actually dominates the total.

That the mean is the right statistic. Skewed distributions make means misleading. If one nine-hour incident and nine four-minute ones produce a reassuring average, the average is hiding the only incident that mattered.