When a production incident hits, every minute of downtime has a price: lost revenue, eroded user trust, and engineering squads pulled off planned work to fight fires. Mean time to recovery (MTTR) measures how long it takes your team to restore service after a failure. It is one of the four DORA metrics and one of the clearest signals of how resilient your delivery process actually is. This page covers the definition, how to calculate it, published benchmarks, practical ways to improve it, and how DevStats surfaces it for your squad.
Key takeaways
- Mean time to recovery measures the average time between a service failure and full restoration. It matters because long recovery windows translate directly into user-facing downtime, missed SLAs, and unplanned engineering work that crowds out your roadmap.
- MTTR is calculated by dividing the total cumulative recovery time across all incidents by the number of incidents in a given period. According to the 2023 DORA State of DevOps Report, elite-performing teams achieve a mean time to recovery of under one hour.
- The most common mistake teams make is treating MTTR as a measure of individual engineer performance. It is a process metric. A high MTTR usually points to gaps in observability tooling, unclear incident runbooks, or deployment pipelines that make rollbacks slow, not to individual player capability.
- DevStats surfaces DORA metrics including mean time to recovery through its DORA metrics feature, benchmarked against data from 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes at app.devstats.com/register.
Mean time to recovery definition
Mean time to recovery is the average time it takes an engineering team to restore a system to normal operation after a failure or incident. It is calculated from the moment a failure is detected to the moment full service is confirmed as restored.
The formula is: MTTR = Total recovery time across all incidents / Number of incidents. It is typically expressed in hours or minutes and measured over a rolling window, such as 30 or 90 days. MTTR is one of the four core DORA metrics, alongside deployment frequency, lead time for changes, and change failure rate. A low MTTR signals that your squad can detect problems fast, respond with confidence, and restore service before most users notice.
Why mean time to recovery matters for engineering teams
Squads that do not track MTTR often discover the problem the hard way: a post-mortem reveals the team spent six hours recovering from an incident that should have taken thirty minutes. That gap does not show up in velocity metrics or sprint completion rates. It shows up in stakeholder trust and in the unplanned work that silently displaces roadmap commitments across your next two sprints.
For engineering leaders, MTTR connects directly to SLA compliance, on-call burden, and developer retention. High MTTR means your players spend more time in reactive firefighting mode. That erodes both squad productivity and morale over time. When recovery takes hours instead of minutes, the cost is not just downtime; it is the compounding effect of interrupted focus and deferred planned work.
MTTR is one of the stability-side DORA metrics, sitting alongside change failure rate to give you a picture of delivery resilience rather than just delivery speed. Measurement is the starting point. The engineering leader is the one who decides what the data means and what to change.
Teams that pair MTTR data with visibility into their deployment pipeline can start to see whether slow recovery correlates with specific deployment patterns, such as large batch releases or infrequent deploys that make rollbacks harder to execute cleanly.
How to measure mean time to recovery
To calculate MTTR, you need an incident log with two timestamps per incident: when the failure was detected (or when service degraded below threshold) and when full service was confirmed as restored. Most squads pull this from their incident management tool, such as PagerDuty, Opsgenie, or Statuspage. The calculation is straightforward: sum all recovery durations for a given period and divide by the total number of incidents.
The data quality challenge is consistency in how "recovery" is defined. Some teams close an incident when the immediate symptom is resolved; others wait until the root cause is addressed and monitoring confirms stability. Pick one definition and apply it uniformly. Without that discipline, your MTTR trend line is noise. You can see how your numbers compare against industry peers using DevStats benchmarks, which draw on data from over 1,000 engineering teams.
| Performance level | Mean time to recovery benchmark | What it signals |
|---|---|---|
| Elite | Less than 1 hour | Strong observability, fast rollback capability, clear runbooks (DORA 2023) |
| High | Less than 1 day | Solid incident response with some manual steps that add latency (DORA 2023) |
| Medium | 1 day to 1 week | Recovery depends on specific players or lacks automation; process gaps are visible (DORA 2023) |
| Low | More than 1 week | Systemic issues: poor observability, no rollback path, or high coordination overhead (DORA 2023) |
Mean time to recovery in practice: a real example
A VP of Engineering at a 45-person SaaS company noticed that their MTTR had crept from under two hours to nearly six hours over a quarter. The data showed the pattern clearly: incidents were being detected quickly, but time-to-resolution was long. After reviewing the incident log, she identified that most of the delay happened between detection and the first meaningful action, not in the fix itself. The squad lacked a clear on-call escalation path, and runbooks for the three most common failure modes were either missing or outdated.
She ran a two-week sprint dedicated to runbook creation and on-call rotation clarity. The squad documented rollback steps for their five highest-risk deployment scenarios and added automated alerting that linked directly to the relevant runbook. Four weeks later, MTTR dropped back below two hours. The leading indicator she watched was time-to-acknowledge, which fell from 28 minutes to under 8 minutes before the MTTR number moved, confirming the intervention was working before the lagging metric caught up.
How to improve mean time to recovery
- Reduce time-to-detect with better alerting thresholds. Most MTTR problems start before recovery even begins. Audit your current alert configuration and identify gaps where service degradation goes undetected for more than five minutes. Tighten thresholds on your highest-traffic endpoints first.
- Build and maintain rollback runbooks for every deployment type. A slow recovery is often a knowledge problem. Document the exact steps to roll back each type of change your squad ships. Review these runbooks at the start of each sprint cycle so they stay current with your stack.
- Shorten your deployment batch size to make rollbacks cheaper. Large, infrequent releases make rollbacks expensive because reverting one change means reverting many. Smaller, more frequent deploys reduce the blast radius of any single failure. Monitor your deployment frequency as a leading indicator for MTTR improvement.
- Run blameless post-mortems after every incident above a severity threshold. The goal is to surface process gaps, not assign fault. Track action items from post-mortems in your issue tracker and close the loop within two sprints. DevStats can surface issue cycle time data so you can see whether post-mortem action items are actually getting resolved.
- Establish a dedicated incident commander role on-call rotation. When everyone owns recovery, no one does. Assign a single incident commander per shift whose job is coordination, not fixing. This removes the ambiguity that adds 30 to 60 minutes to most recoveries.
Mean time to recovery vs. mean time to detect
Mean time to recovery and mean time to detect (MTTD) are related but measure different failure response phases. MTTR covers the full window from failure detection to service restoration, while MTTD measures only how long it takes to notice a failure has occurred in the first place. You can have a fast MTTD and a slow MTTR if your squad detects problems quickly but then takes hours to resolve them.
| Mean time to recovery | Mean time to detect | |
|---|---|---|
| Measures | Time from detection to full service restoration | Time from failure occurrence to first detection |
| Starts when | Failure is detected | Failure actually occurs |
| Ends when | Service is fully restored | Alert fires or team is notified |
| Best for | Measuring response and rollback process quality | Measuring observability and monitoring coverage |
Track both metrics together to understand where your incident response process loses the most time: before or after detection.