How-to
How to Measure and Reduce MTTR in 7 Steps
- Detect and acknowledge
- Diagnose and repair
- Loglune
On this page
MTTR is the mean time a team takes to get a failed system or service working again, averaged over a set of failures, and the R can stand for repair, recovery, resolve, or respond. This guide measures and reduces MTTR in 7 steps: choose which MTTR the team means, record the timestamps that start and stop the clock, calculate the mean, split the time into stages, report deployment failures separately, find the change that reached the affected customer, and restore service with a rollback that needs no deploy.
The steps apply to software services run by a team with an incident process. MTTR for physical equipment uses the same arithmetic and is outside the scope.
What MTTR means
Atlassian’s page Common Incident Management Metrics says MTTR can represent four different measurements, because the R can stand for repair, recovery, respond, or resolve, and advises a team to agree on which MTTR it means before tracking it. The four variants start and stop the clock at different points.
| MTTR variant | Clock starts | Clock stops | What it shows |
|---|---|---|---|
| Mean time to repair | Repair work begins | The system is fully functional again, testing included | How fast the repair work goes |
| Mean time to recovery, or to restore | The system fails | The system is fully operational again | The speed of the whole recovery process |
| Mean time to resolve | The system fails | Work to keep the failure from recurring is done | Recovery plus prevention |
| Mean time to respond | The first alert | The system is fully functional again | Recovery time without the lag before the alert |
The Atlassian page lists related metrics with their formulas.
| Metric | Formula on the Atlassian page |
|---|---|
| MTTR, mean time to recovery | Total downtime ÷ number of incidents |
| MTTA, mean time to acknowledge | Total time from alert to acknowledgment ÷ number of incidents |
| MTBF, mean time between failures | Total operational time ÷ number of failures |
| Availability | MTBF ÷ (MTBF + MTTR) |
Before you measure MTTR
Four inputs decide whether the number means the same thing from month to month.
- An incident record with the times of the failure, the alert, the acknowledgment, the restored service, and the close.
- A rule for which incidents count, such as every incident at or above a severity level.
- A clock rule: wall-clock hours or business hours.
- A cause field that separates deployments, flag or configuration changes, and external failures.
How to measure and reduce MTTR in 7 steps
1. Choose which MTTR your team means
Pick one of the four variants and write its start and stop points into the incident process. Atlassian’s page says the four measurements overlap but each has its own meaning, and that a team talking about tracking MTTR should first clarify which MTTR it means. For a customer-facing service, mean time to recovery covers the whole outage, from the failure to full operation.
2. Record the timestamps that start and stop the clock
Record each timestamp when it happens instead of reconstructing it after the incident: the failure start from monitoring or the first customer report, the alert, the acknowledgment, the restored service, and the end of the follow-up work. Atlassian notes that mean time to resolve is most frequently calculated in business hours, and that a team with on-call staff or several locations needs to define how it tracks time for the metric.
3. Calculate MTTR with the formula
MTTR is the total time for the chosen variant divided by the number of incidents. In Atlassian’s example for mean time to recovery, 30 minutes of downtime across two incidents in 24 hours gives an MTTR of 15 minutes. For a month with four incidents that took 12, 45, 20, and 83 minutes from failure to restored service, the total is 160 minutes and the mean time to recovery is 160 ÷ 4 = 40 minutes. The monthly numbers are illustrative.
4. Split MTTR into stages to see where the time goes
A single mean does not show whether the time went to detection, diagnosis, or repair. Atlassian’s page describes layering the variants: mean time to recovery shows how quickly systems come back, adding mean time to respond shows how much of the recovery time belongs to the team and how much to the alert system, and adding mean time to repair separates repair time from diagnosis time. The same page describes MTTA as a measure of the team’s responsiveness that can expose alert fatigue.
Record three stage durations per incident: failure to alert, alert to acknowledgment, and acknowledgment to restored service. The stage with the largest share is the first place to shorten.
5. Report failures caused by deployments separately
DORA’s post A history of DORA’s software delivery metrics (January 2, 2026) says DORA renamed and redefined mean time to recover, or time to restore service, as failed deployment recovery time in 2023. The reason given is that the earlier definitions did not distinguish a failure initiated by a software change from a failure caused by external factors, such as a data center outage. DORA’s guide to its software delivery performance metrics (last updated January 5, 2026) defines failed deployment recovery time as the time it takes to recover from a deployment that fails and requires immediate intervention.
Tag each incident with its cause, then report mean time to recovery for all incidents and failed deployment recovery time for the incidents a deployment caused. Decide whether flag and configuration changes count with deployments and write the rule down, because DORA’s definition names deployments. The DORA guide also says the metrics suit one application or service at a time, and cautions that setting the numbers of very different applications side by side, a mobile app next to a mainframe system for instance, gives a misleading picture.
6. Find which change reached the affected customer
In an incident caused by a change, part of the time between acknowledgment and restored service goes to working out which changes were live for the affected customer when the failure started: the build, the configuration, and the flag rules. Build versions come from the deploy log. Flag rules can change several times a day without a deploy, so the flag state at the failure time needs its own record.
In Loglune, every flag edit is appended to the change history as a change event with the customer, the actor, the time, the target flag, and the values before and after. Pick the affected customer and the time the failure started, and Loglune rebuilds the flag state at that time from the change history and delivers it in reproduction mode to a development, CI, or staging environment. One delivery counts as one reproduction, and Loglune reproduces the flag evaluation, not the root cause in application code. The walkthrough on reproducing a bug that affects one customer shows the path from a customer report to a reproduction.
7. Restore service with a rollback that needs no deploy
The Google SRE book chapter Managing Incidents lists the priorities of an incident as stopping the bleeding, restoring service, and preserving the evidence for root-causing. A flag that switches the new code path off restores service without a build and a deploy. Pete Hodgson’s article Feature Toggles (October 9, 2017) says ops toggles have to be re-configured extremely quickly when operations staff react to production issues, and that rolling out a new release to flip one is unlikely to satisfy them.
In Loglune, the edit that switches a flag off is itself a change event with the actor and the time, so the rollback keeps the evidence the incident review needs.
Editorial example (not a customer case): one month of incidents and where the time went
The table splits four incidents into stages. Times and causes are illustrative.
| Incident | Failure to alert | Alert to acknowledgment | Acknowledgment to restored | Failure to restored |
|---|---|---|---|---|
| 1, database failover | 0 min | 3 min | 9 min | 12 min |
| 2, flag rule edit put one customer on a new pricing path | 10 min | 5 min | 30 min | 45 min |
| 3, deployment with a slow query | 2 min | 4 min | 14 min | 20 min |
| 4, third-party API outage | 5 min | 8 min | 70 min | 83 min |
The mean time to recovery for the month is (12 + 45 + 20 + 83) ÷ 4 = 40 minutes. The failed deployment recovery time covers incident 3 alone, at 20 minutes. Incident 2 spent 30 of its 45 minutes between acknowledgment and restored service, and in the example most of that went to finding that a flag rule edit had put the reporting customer on the new pricing path. Rebuilding that customer’s flag state at the failure time shows the value the customer received, and switching the rule back restores service without a deploy.
Troubleshooting MTTR
- MTTR looks low while customers report long outages: check whether the clock starts at the alert, because mean time to respond leaves out the lag before the alert, as Atlassian’s page notes.
- Two teams report different MTTR for the same incidents: agree on the variant and the clock rule, business hours or wall-clock hours.
- One long incident swings the monthly mean: publish the incident list with the stage split next to the mean, because DORA warns against measuring a complex system with one metric.
- MTTR jumps after a change in which incidents count: keep the severity rule fixed, and compare periods under the same rule.
- Incidents close early to improve the number: stop setting MTTR as a target, because DORA warns that setting metrics as goals makes teams more likely to game them.
- Diagnosis takes most of the time in change-caused incidents: record every flag and configuration change with its time and actor, and rebuild the affected customer’s flag state at the failure time.
FAQ
What does MTTR stand for?
MTTR stands for mean time to repair, mean time to recovery (also called mean time to restore), mean time to resolve, or mean time to respond, depending on the team. Atlassian’s page treats the four as overlapping measurements with their own meanings, so a team states which one it reports.
How do you calculate MTTR?
Divide the total time for the chosen variant by the number of incidents in the period. For mean time to recovery, the total is the downtime from each failure to full operation, so 30 minutes of downtime across two incidents gives an MTTR of 15 minutes in Atlassian’s example.
What is a good MTTR?
No single target fits every service. DORA says context matters and that the metrics suit one application or service at a time, and Atlassian’s page notes that MTTR also depends on the severity of failures. Compare a service’s MTTR with its own earlier periods under the same counting rule.
Is MTTR still one of the DORA metrics?
MTTR is no longer a DORA metric under that name. DORA replaced it with failed deployment recovery time in 2023, and since 2024 DORA uses five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate.
Deciding which MTTR to report
Report mean time to recovery for a customer-facing service with the stage split beside it, and report failed deployment recovery time for the incidents a deployment caused. Keep the counting rule fixed across periods and compare a service with its own history. Record every flag change with its time, so the diagnosis stage of a change-caused incident starts from the flag state the affected customer had when the failure began.
Find the flag state an affected customer had during an incident
In a change-caused incident, part of the recovery time goes to working out which change reached the affected customer. Loglune records every flag edit as a change event with the actor, the time, and the values before and after, and rebuilds the flag state a customer had at time T for your development, CI, or staging environment. The Free plan includes 5 reproductions.