Why DORA Dropped MTTR (2026)
DORA no longer uses MTTR. It renamed the metric, added a fifth, and the reason exposes what MTTR actually measured wrong. What to track instead.
Key Takeaways
- DORA no longer publishes an MTTR metric. Its four keys guide names the recovery metric "Failed deployment recovery time" and describes "the move from MTTR to Failed Deployment Recovery Time."
- The reason is precise, not cosmetic. DORA's metrics history explains that earlier definitions "did not distinguish between a failure initiated by a software change and a failure caused by external factors." MTTR blended two different things into one average.
- The rename happened in 2023. Per DORA's history, "time to restore service" became "failed deployment recovery time" specifically to scope the metric to failures a deployment caused, making it statistically consistent with the other delivery metrics.
- There are now five keys, not four. DORA added "Deployment rework rate" in 2024, defined as the "ratio of deployments that are unplanned but happen as a result of an incident in production."
- "MTTR" is not a Google SRE term either. Google's reliability canon is built on SLOs and error budgets, not on a single mean-time-to-restore number. Two of the most cited reliability sources have moved away from MTTR, in different directions.
- The practical fix is to stop averaging unlike incidents. A mean across a config typo and a multi-region cascade is a number that describes neither. Scope recovery time to change-induced failures, and measure the rework those failures generate.
- AI investigation affects recovery time by compressing diagnosis, but only the change-scoped version of the metric can show it cleanly.
DORA dropped MTTR because a single mean time to restore averaged together failures with fundamentally different causes, hiding rather than revealing what a team could act on; it replaced the metric with "failed deployment recovery time," scoped specifically to failures a deployment caused, and added a fifth metric for the rework those failures generate. For any reliability team still reporting MTTR to leadership, the standards body that popularised delivery metrics has already explained why that number misleads. This post works from DORA's own primary documentation and covers what to measure instead.
MTTR is not wrong because it is old. It is wrong because it answers a different question than the one teams think they are asking, and DORA's revision makes the better question explicit.
Does DORA still use MTTR?
No. The DORA four keys guide names the recovery metric "Failed deployment recovery time" and references, in its own words, "the move from MTTR to Failed Deployment Recovery Time." The page defines it as:
"The time it takes to recover from a deployment that fails and requires immediate intervention."
Note what that definition excludes. It is not the time to recover from any incident. It is the time to recover from a deployment that failed. An outage caused by a cloud provider region going down, a third-party API failing, or a certificate expiring that nobody deployed is not in scope. That narrowing is the entire point, and it is what "MTTR" quietly refused to do.
Why did DORA change the metric?
The rationale is stated directly in DORA's metrics history, and it is worth reading precisely because most teams have never seen it. The old metric was ambiguous because, in DORA's framing, "previous definitions did not distinguish between a failure initiated by a software change and a failure caused by external factors."
That is the whole problem in one sentence. "Mean time to restore" pools two populations that behave nothing alike:
- Change-induced failures. A deploy broke something. The recovery lever is your delivery pipeline: rollback speed, canary coverage, feature flags. This is a metric you can improve by engineering.
- Externally-caused failures. A dependency failed, hardware died, a region went dark. The recovery lever is failover and redundancy, a different discipline entirely.
Averaging them produces a number that describes neither. A team that gets very good at fast rollbacks can watch its MTTR barely move because a couple of long externally-caused outages dominate the mean. The metric hides the improvement it was supposed to reward. DORA's fix was to scope the metric to change-induced failures so it becomes, in their words, statistically consistent with the other delivery metrics, all of which are about deployments.
The change happened in 2023, when "time to restore service" was renamed to "failed deployment recovery time."
What is the fifth DORA metric?
Most teams still say "the four keys." As of 2024 there are five. DORA added "Deployment rework rate," and the four keys guide defines it as:
"The ratio of deployments that are unplanned but happen as a result of an incident in production."
The history page explains why: researchers found that change fail rate functioned as "a proxy for the amount of rework a team must perform," and the fifth metric measures that rework directly rather than by proxy. It captures the unplanned deployments you make to fix bugs that a previous deployment introduced.
Here is the current set, which is what a 2026 reliability dashboard should reflect.
| DORA metric | Definition (DORA's wording) | Type |
|---|---|---|
| Change lead time | "The amount of time it takes for a change to go from committed to version control to deployed in production." | Throughput |
| Deployment frequency | "The number of deployments over a given period or the time between deployments." | Throughput |
| Failed deployment recovery time | "The time it takes to recover from a deployment that fails and requires immediate intervention." | Throughput |
| Change fail rate | "The ratio of deployments that require immediate intervention following a deployment." | Instability |
| Deployment rework rate | "The ratio of deployments that are unplanned but happen as a result of an incident in production." | Instability |
If a team's metrics still stop at four, and label the recovery one "MTTR," the dashboard is three years behind the standard it is citing.
Is MTTR a bad metric everywhere, or just for DORA?
It is worth being fair here, because "MTTR is dead" is an overclaim and this post is not making it. MTTR as an operational descriptor, how long incidents take to resolve on average, still has uses for capacity planning and for spotting a trend. The specific critique is narrower and stronger: MTTR is a poor delivery-performance metric because it pools change-induced and external failures, and that is the use DORA retired it from.
The other major reliability tradition never centred it at all. Google's SRE practice is built on service level objectives and error budgets, not on a single mean-time-to-restore figure. That is not an accident. An SLO frames reliability as a target you spend against, which absorbs the fact that some incidents are long and some are short without pretending their average is meaningful. This is why the SLO-based approach and DORA's scoped recovery metric point in the same direction: away from a single blended average and toward measures that separate what a team controls from what it does not.
What should reliability teams measure in 2026?
Ordered by how much the change buys you.
- Scope recovery time to change-induced failures. Stop averaging a config typo against a multi-region cloud outage. Report failed deployment recovery time for failures a deploy caused, and track externally-caused recovery separately if you track it at all, since it measures a different discipline.
- Add deployment rework rate. The unplanned deploys you make to fix what a previous deploy broke are a direct measure of instability, and they are the number that connects delivery speed to delivery quality.
- Keep change fail rate honest. It is the ratio of deployments requiring immediate intervention. If it is near zero, either the pipeline is excellent or the definition is being gamed; check which.
- Frame reliability with SLOs, not a single average. An error budget tells you whether you can afford to ship, which is the decision the metric is supposed to inform. A blended MTTR does not.
- Instrument recovery so the metric is trustworthy. Failed deployment recovery time is only meaningful if you can reliably tie a failure to the deployment that caused it, which requires knowing what actually shipped, not just what merged.
That last point is where change attribution becomes load-bearing, and it is exactly where a poorly-instrumented team ends up guessing.
Where AI investigation fits, and its honest limit
Failed deployment recovery time has two components: time to diagnose and time to remediate. AI investigation attacks the first. Reading logs, correlating an error onset with a specific deploy, and assembling a cited hypothesis is the diagnosis work, and it is the part that scales badly for a human under pressure. Compressing it shortens the recovery clock on exactly the change-induced failures DORA's metric now isolates.
There is a real limit, and it is the same one that runs through honest reliability work. An agent that ties the wrong deploy to the failure produces a fast recovery time on paper and a wrong fix in production. The metric improves while the outcome degrades. This is why change attribution has to be evidence-grounded rather than confident, and why an agent that cannot distinguish "merged" from "actually deployed" will corrupt the very metric it appears to help. Aurora's investigation prompts encode that merged does not always mean deployed, and its findings must state what was ruled out rather than assert a single cause, which is the behaviour that keeps a recovery-time number honest. That discipline is covered in the accuracy guide and is readable in the open repository.
The summary
DORA dropped MTTR because a single mean time to restore averaged together failures a deployment caused and failures it did not, hiding the improvements a team could actually make. It renamed the metric to failed deployment recovery time in 2023, scoped it to change-induced failures, and added deployment rework rate in 2024 to measure the unplanned work instability generates. The lesson generalises: stop reporting a blended average that describes no real population, separate what your pipeline controls from what it does not, and frame reliability with SLOs. AI investigation can shorten the diagnosis half of recovery time, but only a change-scoped, evidence-grounded metric can show that cleanly, and only if the attribution underneath it is honest.
Measure change-scoped recovery on your own stack
Aurora is Apache 2.0, so you can test whether AI investigation shortens diagnosis on your own change-induced failures rather than trusting a claim. The only external requirement is one LLM API key; cloud connectors are optional.
git clone https://github.com/arvo-ai/aurora.git && cd aurora
make init # generates secrets, copies .env.example to .env
nano .env # add OPENROUTER_API_KEY (or OPENAI_API_KEY / ANTHROPIC_API_KEY)
make prod-prebuilt # pulls prebuilt images from GHCR and starts
Open http://localhost:3000. The first user to register becomes admin.
- Start free: aurora-ai.net (hosted, no infrastructure to run)
- GitHub: github.com/Arvo-AI/aurora
- Related guides: SLOs for AI Agents · AI SRE Accuracy: What the Benchmarks Show · The SRE Incident Lifecycle · Root Cause Analysis for SREs
Sourcing note. Metric names, definitions, and the rationale for the MTTR change are quoted from DORA's "DORA's software delivery performance metrics" guide and its "A history of DORA's software delivery metrics" page. The rename to failed deployment recovery time is dated 2023 and the addition of deployment rework rate 2024, per DORA's history. No Aurora recovery-time or MTTR-reduction figure is claimed. Verified August 22, 2026.