Back to Defect metrics
🐛 Defect

Mean time to repair (MTTR)

The average time from defect detection to deployed fix — a measure of how quickly your team resolves confirmed issues.

defectrepair-timefeedback-loop

// Formula

avg(deploy-fix timedetection time)

// About this metric

Mean time to repair (MTTR) for defects measures how quickly your team can go from "defect detected" to "fix deployed". Unlike MTTR for production incidents — which measures speed of service restoration — this MTTR measures the full repair cycle: triage, root cause analysis, fix implementation, code review, and deployment.

The formula is the average across a sample of defects of: (deploy-fix time − detection time). It is most meaningful when calculated separately by severity — your P1/critical MTTR and your P4/trivial MTTR will, and should, be very different numbers.

DORA research and Google's SRE Book provide the directional benchmarks used here: under 8 hours for fast teams, 8–48 hours for typical, and above 48 hours flagging slow repair throughput. These benchmarks blend pre-release and production defects, so treat them as directional rather than precise targets.

MTTR is affected by factors outside engineering control: waiting for sign-off, deployment windows, and downstream dependencies. A consistently high MTTR in a team that writes fixes quickly often points to process overhead rather than engineering capacity.

// Calculator

🧮 Calculator

Your average MTTR8.0hours per defect

// Benchmark

You're in the 'Typical' range — 8.00 hours per defect.

Source: Aggregated from DORA reports and Google SRE Book

Severity-weighted MTTR is usually more informative than raw MTTR — critical fixes shouldn't have the same target as low-priority defects.

// When to use this metric

Use MTTR to identify bottlenecks in your defect resolution process. If MTTR is high, break it down into phases — time-to-triage, time-to-fix, time-to-deploy — to locate where time is actually being lost.

Track MTTR by severity tier separately. A global average that looks acceptable can hide an unacceptable P1 MTTR masked by fast resolution of low-severity defects.

// Common pitfall

MTTR is easy to game by closing defects before the fix is verified, then reopening them as "new" defects. Watch for patterns of duplicate or reopened defects — they are a signal that MTTR is being measured at "closed", not at "verified fixed in production".