Skip to main content
MTTR stands for mean time to resolution: the average time it takes to fully resolve an incident, measured from the moment the incident begins to the moment service is restored and the fix is complete. It is calculated by dividing total resolution time across a set of incidents by the number of incidents. MTTR is the most widely used measure of how quickly a team recovers from failure.

​
What does MTTR stand for?

The “R” in MTTR is ambiguous, and the four common expansions measure genuinely different things. When someone quotes an MTTR number, always confirm which definition they mean — comparing “time to respond” against “time to resolution” makes a team look either heroic or terrible for no reason. Mean time to recovery and mean time to repair often differ: rolling back a bad deploy restores service in minutes (recovery) even if the underlying bug takes days to fix (repair). Mean time to respond is closer to MTTA territory — it measures the front end of the incident, not the fix.

​
How do you calculate MTTR?

Resolution time for each incident runs from the incident’s start time (or detection time, depending on your convention — pick one and apply it consistently) to its resolved timestamp.

​
Worked example

A team handles four incidents in a month:
  • Incident 1: resolved in 45 minutes
  • Incident 2: resolved in 2 hours (120 minutes)
  • Incident 3: resolved in 30 minutes
  • Incident 4: resolved in 3 hours 25 minutes (205 minutes)
Total resolution time = 45 + 120 + 30 + 205 = 400 minutes. MTTR = 400 / 4 = 100 minutes, or 1 hour 40 minutes. Because it is a mean, one long-running incident can drag the number dramatically. Many teams track the median and the 90th percentile alongside MTTR, and segment by severity, so a single messy SEV1 doesn’t hide steady improvement everywhere else.

​
What is a good MTTR?

There is no universal benchmark, and be skeptical of anyone selling one. A “good” MTTR depends on:
  • Severity. A SEV1 outage and a SEV4 cosmetic bug should never share a target. Most teams set per-severity goals.
  • Industry and risk profile. A payments platform tolerates far less downtime than an internal analytics tool.
  • Architecture. Systems designed for fast rollback and graceful degradation recover faster by construction.
  • Definition. Resolution, repair, recovery, and respond produce very different numbers for the same incidents.
The most useful comparison is your own trend line: is MTTR for each severity level going down quarter over quarter?

​
How do you reduce MTTR?

MTTR compresses when you shorten each phase of the incident:
  1. Detect faster. Better alerting and monitoring coverage means the clock starts closer to the actual failure.
  2. Acknowledge and mobilize faster. Clear on-call schedules and escalation policies reduce the gap between alert and action — this is what MTTA measures.
  3. Diagnose faster. Runbooks, service catalogs, and searchable history of past incidents cut investigation time.
  4. Fix faster. Practiced rollback procedures, feature flags, and automation beat improvising under pressure.
  5. Learn. Retrospectives that produce completed action items prevent repeat incidents and make the next one shorter.
Rootly computes MTTR automatically from incident timestamps, segmented by severity, service, and team — see default metrics for how each duration is derived. Browse the full incident management glossary.