Engineering:Mean time to recovery
Mean time to recovery (MTTR), also known as mean time to repair or mean time to resolve,[1][2][3] is the average time that a device or system will take to recover from any failure. Examples of such devices range from self-resetting fuses (where the MTTR would be very short, probably seconds), to whole systems which have to be repaired or replaced.
The MTTR would usually be part of a maintenance contract, where the user would pay more for a system MTTR of which was 24 hours, than for one of, say, 7 days. This does not mean the supplier is guaranteeing to have the system up and running again within 24 hours (or 7 days) of being notified of the failure. It does mean the average repair time will tend towards 24 hours (or 7 days). A more useful maintenance contract measure is the maximum time to recovery which can be easily measured and the supplier held accountably.
Note that some suppliers will interpret MTTR to mean 'mean time to respond' and others will take it to mean 'mean time to replace/repair/recover/resolve'. The former indicates that the supplier will acknowledge a problem and initiate mitigation within a certain timeframe. Some systems may have an MTTR of zero, which means that they have redundant components which can take over the instant the primary one fails, see RAID for example. However, the failed device involved in this redundant configuration still needs to be returned to service and hence the device itself has a non-zero MTTR even if the system as a whole (through redundancy) has an MTTR of zero. But, as long as service is maintained, this is a minor issue.
Calculation
MTTR is calculated by dividing the total time spent on repairs or recovery across a set of incidents by the number of incidents:[4]
For example, if a service experienced four incidents in a month with resolution times of 8, 23, 45, and 12 minutes, the MTTR for that period would be (8 + 23 + 45 + 12) ÷ 4 = 22 minutes.
Components
In incident management for software systems, MTTR encompasses several sequential phases, each of which contributes to the total recovery time:[5]
- Detection — the time between the failure occurring and monitoring systems identifying it. Also measured independently as mean time to detect (MTTD).
- Notification — the time for an alert to reach the responsible engineer or on-call team.
- Acknowledgment — the time for the responder to begin investigating. Also measured independently as mean time to acknowledge (MTTA).
- Diagnosis — the time to identify the root cause of the failure.
- Remediation — the time to apply a fix (e.g., rollback, restart, configuration change).
- Verification — the time to confirm the service has returned to normal operation.
Detection time is often the largest controllable factor. A monitoring system that checks every 5 minutes adds an average of 2.5 minutes to every incident's MTTR compared to one that checks every 30 seconds.[6]
Related metrics
MTTR is part of a family of metrics used in reliability engineering and incident management:
| Metric | Full name | Measures |
|---|---|---|
| MTTD | Mean time to detect | Time from failure to first alert |
| MTTA | Mean time to acknowledge | Time from alert to engineer response |
| MTTR | Mean time to recovery | Total time from failure to service restoration |
| MTBF | Mean time between failures | Time between consecutive failures (measures reliability) |
| Mean time to repair | Mean time to repair | Time spent on the repair activity itself (subset of MTTR) |
MTBF and MTTR are inversely related to system availability: a system with high MTBF and low MTTR will have higher availability than one with low MTBF and high MTTR.[7]
See also
- Mean time to repair
- Mean time between failures
- Mean down time
- Service-level agreement
- Incident management
- Postmortem documentation
References
- ↑ "Also refer to "Mean Time To Repair" or "Mean Time To Restore"". https://www.pcmag.com/encyclopedia_term/0,2542,t=mean+time+to+repair&i=47418,00.asp.
- ↑ INTEL call for Mean-Time-to-Repair on page 4 left. "Unknown". http://download.intel.com/design/servers/ism/docs/317987.pdf.
- ↑ Atlassian. "MTBF, MTTR, MTTF, MTTA: Understanding incident metrics" (in en). https://www.atlassian.com/incident-management/kpis/common-metrics.
- ↑ Atlassian. "MTBF, MTTR, MTTF, MTTA: Understanding incident metrics" (in en). https://www.atlassian.com/incident-management/kpis/common-metrics.
- ↑ "What Is MTTR and How to Reduce It". Vantaj Blog. 2026-06-20. https://vantaj.co/blog/what-is-mttr.
- ↑ "What Is MTTR and How to Reduce It". Vantaj Blog. 2026-06-20. https://vantaj.co/blog/what-is-mttr.
- ↑ Atlassian. "MTBF, MTTR, MTTF, MTTA: Understanding incident metrics" (in en). https://www.atlassian.com/incident-management/kpis/common-metrics.
