MTTR is an average time measured from the start of a failure to a defined end point, but the letter R has four common meanings: repair, recover, respond and resolve. They measure different spans, so a number is only useful if you state which one it is, where the clock starts and where it stops.
What are the four versions?
- Mean time to repair. The average time to fix a failed component, from when work starts to when it is working again. It comes from hardware reliability, where it describes maintenance effort.
- Mean time to recover (or restore). The average time from failure until service is back for users, including detection and waiting. This is what customers feel.
- Mean time to respond. The average time from alert to the first response action or acknowledgement.
- Mean time to resolve. The average time until the issue is closed, including the permanent fix and follow up.
One incident, four clocks. If a database fails at 02:00, the alert fires at 02:10, an engineer acknowledges at 02:25, service is restored at 03:30 and the root cause fix ships at 14:00, then respond is 15 minutes after the alert, recover is 90 minutes, and resolve is 12 hours.
Where does security use it?
Security teams track time to detect and time to contain next to time to recover. NIST's incident response guidance, SP 800-61 Rev. 3, places incident response inside broader cybersecurity risk management, with functions for detecting, responding and recovering. MTTR sits across those functions, so a security MTTR needs a rule about whether the clock starts at compromise, at detection or at ticket creation. These can differ by weeks.
The same idea applies to vulnerabilities: time from a fix being available to it being deployed is a close cousin and often more actionable than a general average.
In software delivery, the DORA research program tracks failed deployment recovery time, described as the time it takes to recover from a deployment that fails and requires immediate intervention. That is a recovery definition scoped to deployments.
Why do averages mislead?
Incident durations are lopsided. Most are short and a few are very long. One 40 hour outage among twenty 30 minute ones drags the mean to more than two hours, a number that describes none of them. The mean can also hide improvement or decline, because a single extreme event swings it.
Better practice:
- Report the median and a high percentile such as the 90th, alongside the mean.
- Segment by severity. A severity one outage and a minor glitch should not share an average.
- Show the distribution or a chart of every incident, not just one number.
- Track the count too. A falling MTTR with a rising incident count is not clearly good.
Constructed example: a team's quarterly MTTR drops from 6 hours to 4. Looking at the list, they find that the long incident from last quarter simply did not recur, and the typical incident is unchanged at 45 minutes. The headline improved with no change in how they work.
What drives it down?
Detection speed, clear ownership and on call, runbooks, easy rollback, good observability, small changes and rehearsal. Automating a safe first response helps most when the remedy is well understood. For vulnerabilities, knowing which flaws are reachable shortens triage, and Safeguard offers reachability analysis and fix pull requests that are off by default until you enable them.
How to check or apply this
- Pick one definition and write it down: name, start event, end event.
- Source the timestamps from your incident tool, not from memory.
- Report median, 90th percentile and count, by severity.
- Review the three longest incidents each month and ask where time was lost: detection, escalation, diagnosis or fix.
- Set a target for a specific phase you can influence.
- Revisit the definition if the process changes.
Quick check
Which MTTR should a customer facing team use?
Mean time to recover, because it matches what users experience. Track respond and resolve as supporting measures.
Is a lower MTTR always better?
Not on its own. It can fall because incidents are closed early, reclassified or split. Check reopen rates and customer impact alongside it.
Sources
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- DORA, software delivery performance metrics
Last reviewed: 18 October 2026.
