Definition
MTTR (mean time to resolution, repair, respond or recover) is the average elapsed time between the start of an incident and the point the chosen definition treats as its end, measured across incidents in a period. The formula is total incident time divided by the number of incidents. Teams must state which end point they use, because the four variants measure different things.
Explanation
Mean time to respond measures to the first human action. Mean time to repair measures to the fix being applied. Mean time to recover measures to service being back for users, close to DORA’s “time to restore service”, which DORA has since renamed failed deployment recovery time. Mean time to resolve measures to the incident being closed, including verification. Whichever you pick, most of the time in a cloud incident is not detection. Alerts fire in seconds, and the minutes go to a person reading dashboards, finding what changed, deciding on a fix and applying it. That is why faster alerts barely move MTTR, and why remediation speed is where the metric moves.
How DataAgent approaches it
DataAgent works on the interval where MTTR actually goes. Each incident gets a root cause within seconds of detection and a remediation plan, and the approach is to restore service first and investigate after. The post How to reduce MTTR breaks an incident into its intervals.
Example
Four incidents in a month last 25, 40, 140 and 35 minutes from alert to confirmed fix: MTTR = 240 / 4 = 60 minutes. In the 140-minute incident, the alert fired at minute 0, the engineer acknowledged at minute 6, found the config change at minute 95, and the rollback finished at minute 120. Detection was a few seconds. Finding the cause was 89 of the 140 minutes.
Related terms
- MTTR vs MTTA vs MTTD
- Remediation vs mitigation
- DORA metrics
- Incident remediation
- Automated root cause analysis
FAQ
- Which MTTR should an SRE team track?
- Mean time to recover (service restored for users) matches DORA and user impact. Track mean time to resolve separately if postmortem follow-ups are slow, and state both definitions on the dashboard.
- What is a good MTTR?
- It depends on the service’s SLO and on what counts as an incident. Compare your own trend over time and by fault class rather than against published averages, which mix definitions.
- Does MTTR include detection time?
- Only if the start point is the fault rather than the alert. Many teams measure from alert to recovery and track detection time (MTTD) separately.