What Is Mean Time to Recovery (MTTR)?

MTTR, or mean time to recovery, is the average time it takes to restore a service after a failure, calculated as total recovery time divided by the number of incidents. In software delivery, it shows how quickly a team gets users a working service again when a change goes wrong.

In the DORA set, MTTR sits beside deployment frequency and lead time for changes.

The R in MTTR has four common meanings, each measuring slightly different stretches of an incident, so teams should agree on one before they compare numbers.

DORA, the research program behind the best-known delivery metrics, no longer uses the name MTTR. Since 2023 it has measured failed deployment recovery time, which only counts failures caused by a change to production.

What Changed in MTTR in 2026

At the start of 2026, AI incident tooling was mostly in preview. During the year, cloud providers made AI agents for site reliability engineering generally available, while incidents outpaced code output.

AI agents became a standard part of incident response. Microsoft made its Azure SRE Agent generally available (March 10, 2026, Microsoft), and AWS made its DevOps Agent generally available (March 31, 2026, AWS). Both agents investigate incidents and suggest likely causes.

Teams also had more incidents to recover from, relative to the code they shipped:

• Incidents outpaced PRs: monthly incidents went up 57.9%, and the ratio of incidents to PRs went up 242.7% (April 12, 2026, Faros AI).
• Most organizations have already had an AI-related incident: 89% of organizations surveyed reported an AI-related production incident (August 2026, Qodo’s State of AI Code Quality report).

MTTR benchmarks stay on 2025 data for now. DORA published a history of its metrics explaining why MTTR became failed deployment recovery time (January 2, 2026, DORA), and DORA won’t publish a 2026 report (September 3, 2026, LeadDev).

For recovery time, quicker diagnosis helps, but the bigger lever is fewer changes that need a recovery at all, which is where review comes in.

How to Calculate MTTR

MTTR = total recovery time for all incidents / number of incidents

For example, three incidents that took 30 minutes, 2 hours and 4 hours to recover add up to 6.5 hours. Divided by three, the MTTR is about 2.2 hours.

1. Choose a time window, such as the last 90 days.
2. List every incident in that window that affected users.
3. Record when each one started and when service was restored.
4. Add up the recovery times and divide by the number of incidents.

A single long outage can pull the average up, so many teams track the median as well.

MTTR vs Failed Deployment Recovery Time and Related Metrics

DORA counts failed deployment recovery time as a throughput metric (last checked October 2026, DORA’s metrics guide). See DORA metrics for the full set, and change failure rate for how often deployments fail.

DORA’s 2025 report also dropped fixed performance tiers for seven team profiles, so there is no current DORA "elite" recovery threshold to quote (last checked October 2026, DORA’s 2025 report).

Where Recovery Time Goes

Detecting the Failure

Recovery can’t start until someone knows something is wrong. Alerting on user-facing symptoms shortens this stretch.

Finding the Change That Caused It

For change-related failures, much of an incident is spent working out what changed. Teams look through recent deploys, merged PRs and commits to find the cause.

Deciding How to Fix It

A rollback is often quickest when the bad change is isolated. When it isn’t, the team writes a fix and ships it forward.

Reviewing and Shipping the Fix

Hotfixes are written under pressure, and a rushed fix can cause the next incident. A quick, focused review of the fix protects the recovery.

How Code Review Shortens Recovery

Code review mostly works before an incident, but it shapes how long recovery takes:

• Smaller changes, such as stacked pull requests, are easier to find and roll back when something breaks.
• Clear PR descriptions tell the on-call engineer what a change was meant to do.
• Logging and error handling checked in review, such as structured logging, make the next failure quicker to diagnose.
• Review history shows how similar problems were fixed before.
• A reviewed hotfix is less likely to cause a second incident.

Qodo’s Take: Recovery Is Quicker When the Failure Never Ships, or Is Easy to Diagnose When It Does

Most MTTR advice starts after the alert fires. But the code decides two things before that: how likely a failure is, and how long it takes to understand. A swallowed error or a missing log can turn a ten-minute fix into an afternoon of guessing.

Review is where those gaps are cheapest to close. Qodo isn’t an incident-response tool, and it doesn’t monitor production or measure MTTR. Qodo works on the code side, before and after an incident.

Teams responsible for production stability often worry that a review gate will slow an urgent fix in the middle of an incident. Qodo’s review is advisory: it comments on the fix like any other PR, and merge rules stay with the team’s branch protection, so the team decides how urgent fixes merge.

Teams that share on-call across time zones also need reviews that don’t wait overnight; see code review tools for distributed teams.

Qodo is the best AI code review platform to cut the incidents behind MTTR because every PR is checked for the reliability and observability gaps, such as unhandled errors, missing retries or timeouts, swallowed errors and missing logs, that make failures both likelier and slower to diagnose.

Qodo Flags Reliability and Observability Gaps in Review

Qodo’s findings include a Reliability category, such as missing retries or timeouts.

An Observability category covers gaps in monitoring and debugging in production, such as missing logs, swallowed errors and no metrics on critical paths (last checked October 2026, Qodo’s docs). Teams can also write their own rules in these categories, checked once Rule enforcement is on.

Qodo Helps Trace Regressions to Recent Changes

Codebase Wisdom, part of Qodo’s Agentic Toolbox, gives a coding agent access to repositories, PR history and Git history, so an engineer can ask which recent changes touched a failing component (last checked October 2026, Qodo’s docs).

Qodo Reviews the Fix Like Any Other Change

A fix PR gets the same review as any change, including a check for breaking changes in upstream or downstream consumers (last checked October 2026, Qodo’s docs). Review effort mode, in Beta, can route a small change to sensitive code to a deep review (Qodo’s docs).

Qodo Example: The Swallowed Error

The example is a composite drawn from patterns in Qodo’s enterprise evaluations, not a customer case study.

A lead responsible for production stability wants fewer silent failures and a review step that won’t hold up an urgent fix.

A PR wraps a payment call in a try block that catches every exception and returns an empty result. Tests pass.

Qodo flags the swallowed error under Observability and a missing timeout under Reliability. The author adds a timeout and logs the failure, so when the payment provider slows down later, the alert names the cause.

Ways to Shorten Recovery Time

The table compares common ways teams shorten MTTR and failed deployment recovery time.

Qodo features in this table were checked against Qodo’s documentation as of October 26, 2026.