What Is MTTR? Mean Time to Repair, Recovery, Respond, or Resolve

Last verified on Nov 8, 2026.

MTTR is the most quoted incident metric and the least consistently defined. The "R" has been read four ways, and the intervals they measure are not interchangeable. Before comparing your number with anyone else's, or with last quarter's, check which one it is.

The Four Meanings

Repair and recovery are about the system. Resolve is about a ticket's life cycle, which can include follow-up work after users have stopped being affected. A team that closes incidents only after the postmortem is filed will report a much longer "resolve" time than one that closes them when service is restored.

Google's SRE book treats MTTR as the number that matters most for emergency response: how quickly the team can bring the system back to health. In that reading it is recovery.

DORA's history page is a useful warning. DORA used "mean time to recover" as one of its original delivery metrics. In 2023 it renamed the metric failed deployment recovery time, because earlier definitions did not distinguish failures caused by a software change from external failures such as a data center outage. The same risk exists inside your own incident data.

The Formula

MTTR = sum of (end - start) for every incident / number of incidents

Pick the start and end once and write them down. A common choice for recovery:

• Start: the first moment users were affected. This often comes from logs and is earlier than the page.
• End: the moment the SLI is back inside its target, not when the fix was deployed.

Computing it from an incident table incidents(id, severity, impact_started_at, detected_at, acknowledged_at, recovered_at):

SELECT severity,
       count(*) AS incidents,
       avg(recovered_at - impact_started_at) AS mean_ttr,
       percentile_cont(0.5) WITHIN GROUP (ORDER BY recovered_at - impact_started_at) AS median_ttr,
       percentile_cont(0.9) WITHIN GROUP (ORDER BY recovered_at - impact_started_at) AS p90_ttr
FROM incidents
WHERE impact_started_at >= now() - interval '90 days'
GROUP BY severity
ORDER BY severity;

Why the Mean Misleads

Incident durations are lopsided. Most are short and a few run for hours. One eight-hour outage among nine 20-minute ones produces a mean of 66 minutes and a median of 20, and the mean describes none of the ten incidents. Report the median and a high percentile next to the mean, and split by severity, so a sev-1 and a minor blip never share an average. The same logic is explained for latency on the latency percentiles page.

With a few incidents per quarter, treat any change as a hint rather than a result. Two bad weeks can swing the average more than any process change.

MTTA

Mean time to acknowledge measures how long it takes for a human to pick up an alert. PagerDuty's analytics docs define it as the average time from incident creation until the first responder acknowledges it, excluding incidents that were never acknowledged. Its MTTR is defined from creation to resolution, excluding unresolved incidents.

Exclusions matter: an incident nobody acknowledged is not counted in MTTA, so a bad week can look better than it was. Check the acknowledgment rate alongside the average.

MTTA covers only the response slice. The time before the alert is its own metric, MTTD. Recovery time is the sum of detection, response, and fix, so each one points at a different improvement.

What Shortens It

The SRE book says that writing down best practices in a playbook ahead of time produced roughly a 3x MTTR improvement compared with improvising. The workbook adds that playbooks reduce stress and the risk of human error as well. Beyond that:

• Detect sooner. You cannot recover from something nobody knows about. See MTTD.
• Make rollback boring. Google's example error budget policy says changes account for roughly 70% of its outages, so undoing a change is often the fastest path back.
• Search all signals in one place. Logs, metrics, and traces split across tools add minutes to every incident.
• Rehearse. A playbook nobody has used is a guess.

Sazabi is an AI-native observability and security platform. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run.

Limits of MTTR

MTTR says nothing about how often things break. A team with one huge incident a year and a team with fifty small ones can have the same average. The SRE book calls reliability a function of both mean time to failure and mean time to repair, so pair it with MTBF and the error budget. For incident types that are repair-driven, see crash loops and third-party failures.