What is MTTR?

#How MTTR is measured

The expansion itself is contested: recovery, repair, resolve, and restore all appear, and they mean different things. Time to restore service and time to repair the underlying cause can differ by days.

The start point varies as well. Measuring from failure onset includes detection time, measuring from alert excludes it, and measuring from acknowledgment excludes both. None is wrong, but comparing MTTR across teams or vendors without knowing the definition is meaningless. What matters is defining it once and applying it consistently.

#Why MTTR matters

MTTR is half of the availability equation, and it is usually the half a team can improve fastest.

• Direct availability impact: halving recovery time halves downtime at constant failure frequency.
• Improvable: tooling, runbooks, and rehearsal produce measurable gains quickly.
• Diagnostic signal: the breakdown across detect, acknowledge, diagnose, and fix shows where time is lost.
• DORA component: it is one of the four delivery performance metrics.

#Limits of MTTR

As an average over a skewed distribution, MTTR is often misleading. Ninety incidents resolved in five minutes and ten taking eight hours produce a respectable mean that describes neither group. Median and 95th percentile carry more information.

It also flattens severity. A trivial incident resolved in two hours and a critical outage resolved in two hours contribute identically, so MTTR should be segmented by severity or it will mostly track the volume of minor incidents.

#MTTR vs MTBF

MTBF is how often failures happen. MTTR is how long they last. Availability depends on both, and the same availability can be reached by failing rarely and recovering slowly or failing often and recovering fast.

The distinction shapes strategy. Improving MTBF means preventing failures through architecture, testing, and change discipline, which is slow and structural. Improving MTTR means detecting and recovering faster, which is more tractable in the short-term. Most teams find the fastest path to better availability runs through MTTR, then MTBF as the system matures.

#Key takeaways

• MTTR has multiple contested definitions, so the endpoints must be defined explicitly and applied consistently.
• Terminology and endpoint definitions vary across organizations and tools; publish the exact local definition alongside the metric.
• It is one half of availability and usually the half a team can improve fastest.
• Averages mislead on skewed incident distributions, so median and 95th percentile are more informative.
• It must be segmented by severity, or it mostly tracks the volume of minor incidents.

#Frequently asked

What is a good MTTR?

It depends entirely on the definition and the service. The useful comparison is your own trend over time rather than an external benchmark.

Should MTTR include detection time?

Including it gives the truest picture of user impact. Whichever choice you make, document it, because it changes the number substantially.

How is MTTR reduced fastest?

By breaking it into detect, acknowledge, diagnose, and fix, then attacking the largest segment. Diagnosis is the largest for most teams.