When a production incident hits, every minute of downtime has a direct cost: lost revenue, eroded user trust, and a squad pulled away from planned work. Time to restore service measures how long it takes your team to recover a degraded or failed system back to normal operation. It is one of the four DORA metrics and one of the clearest signals of your engineering organization's resilience. This page covers the definition, how to measure it against published benchmarks, how to improve it, and how DevStats surfaces it for your team.
Key takeaways
- Time to restore service measures the speed at which your squad recovers a production system after a failure or degradation event. It directly reflects the health of your incident response process and your team's ability to ship fixes under pressure, making it one of the most business-relevant engineering metrics you can track.
- The formula is straightforward: Time to restore service equals the timestamp when service is fully recovered minus the timestamp when the incident was first detected. According to the 2023 DORA State of DevOps report, elite performers restore service in under one hour, while low performers take between one week and one month.
- The most common mistake teams make is conflating time to restore service with mean time to repair (MTTR). MTTR is an average that can mask outlier incidents. Tracking the distribution, including the 90th percentile, gives you a more honest picture of your worst-case recovery scenarios and where process gaps actually live.
- DevStats surfaces DORA metrics including time to restore service by connecting to your Git provider, issue tracker, and deployment pipeline, with benchmarks drawn from 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.
Time to restore service definition
Time to restore service is the amount of time it takes an engineering team to recover a production service from the moment an incident is detected to the moment normal operation is confirmed. It measures the responsiveness of your incident response process, not any individual player's speed.
Technically, the formula is: Time to restore service = Recovery timestamp minus Detection timestamp. This is measured per incident and then aggregated, typically as a median or 90th percentile, across a rolling time window such as 30 or 90 days. Teams that track this metric as part of their DORA metrics program get a quantified view of system resilience that maps directly to customer experience and SLA compliance.
Why time to restore service matters for engineering teams
Squads that do not track time to restore service often discover its importance at the worst possible moment: during a post-mortem after a major outage. Without baseline data, you cannot tell whether your recovery is getting faster or slower over time, and you cannot make a credible case to the business about where reliability investment is needed. Untracked recovery time also means sprint planning absorbs incident work invisibly, distorting your planning accuracy and making velocity metrics misleading.
For engineering leaders, this metric connects directly to stakeholder trust and revenue protection. A slow time to restore service erodes confidence in the platform, increases on-call burnout, and signals that your deployment and rollback processes need attention. Teams with strong deployment pipelines, reviewed through tools like DevStats's deploy insights, tend to restore service faster because they can identify and revert a bad deploy in minutes rather than hours.
Time to restore service is one of the four core DORA metrics, sitting alongside deployment frequency, lead time for changes, and change failure rate. Together they form a balanced view of delivery speed and stability. Measurement is the first step; the engineering leader decides what interventions to make based on what the data reveals about their specific processes.
How to measure time to restore service
To calculate time to restore service, you need two timestamps per incident: when the incident was first detected (via an alert, monitoring tool, or user report) and when the service was confirmed restored. The difference is your raw recovery time. Aggregate across incidents using the median for a typical-case view and the 90th percentile to understand your worst-case exposure. Data sources include your incident management tool (PagerDuty, OpsGenie, or similar), your deployment pipeline, and your monitoring platform. Connecting these to a tool like DevStats's benchmarks feature lets you compare your numbers against peers in similar engineering contexts.
The benchmarks below are drawn from the 2023 DORA State of DevOps report.
| Performance level | Time to restore service benchmark | What it signals |
|---|---|---|
| Elite | Less than one hour | Automated rollback, strong observability, practiced runbooks |
| High | Less than one day | Solid incident process with some manual steps remaining |
| Medium | Between one day and one week | Incident response is reactive and inconsistently documented |
| Low | Between one week and one month | No structured incident process; recovery depends on individual heroics |
Time to restore service in practice: a real example
A VP of Engineering at a 45-person SaaS company noticed that their median time to restore service had crept from four hours to nearly eighteen hours over two quarters. Digging into incident data, she found that most of the delay was not in diagnosing the root cause but in the deployment step: getting a fix through code review, staging, and into production took longer than the investigation itself. Her squad's PR cycle time data confirmed that review turnaround on hotfix branches averaged six hours, even for small changes.
She introduced a dedicated hotfix lane with a two-reviewer maximum and a 30-minute SLA for incident-tagged PRs. She also added a post-incident review template that captured time-to-detect, time-to-diagnose, and time-to-deploy separately. Within 60 days, her team's median time to restore service dropped to under three hours. The fix was not a tool change. It was a process decision made by an engineering leader who had the data to see exactly where time was being lost.
How to improve time to restore service
- Separate your recovery timeline into stages. Break each incident into detection, diagnosis, fix development, and deployment. Measure each stage independently. Most teams discover that deployment, not diagnosis, is the bottleneck. This makes the fix actionable rather than vague.
- Reduce PR cycle time on incident branches. A slow PR cycle time during an incident is a direct multiplier on your recovery time. Define a hotfix process with a shortened review path and communicate it before the next incident happens.
- Build and rehearse runbooks for your top five incident types. Teams that have documented, practiced runbooks restore service faster because players do not spend time rediscovering solutions under pressure. Review runbooks every quarter and update them after each incident.
- Improve deployment pipeline speed and rollback capability. If your squad cannot revert a bad deploy in under ten minutes, your time to restore service will always have a floor set by your pipeline. Invest in one-click rollback and measure deploy lead time as a leading indicator for recovery speed.
- Track change failure rate alongside recovery time. A high change failure rate means more incidents, which means more recovery events. Reducing failures through better code review practices cuts the total time your squad spends in recovery mode across a quarter.
Time to restore service vs. MTTR
Time to restore service and mean time to repair (MTTR) are often used interchangeably, but they measure slightly different things and the distinction affects how you interpret your data.
| Time to restore service | MTTR | |
|---|---|---|
| Measures | Elapsed time per incident from detection to recovery | Average repair time across all incidents in a period |
| Starts when | Incident is detected | Failure occurs (sometimes before detection) |
| Ends when | Service is fully restored | System is repaired (may not include full service validation) |
| Best for | DORA benchmarking, SLA reporting, trend analysis | Reliability engineering, hardware and infrastructure contexts |
Use time to restore service when you want DORA-aligned benchmarking and a user-impact-centered view of recovery. Use MTTR when you are working in infrastructure or hardware reliability contexts where repair and restoration are distinct phases.