Mean time to detect (MTTD)

Mean time to detect (MTTD) measures how quickly your team discovers defects after they are introduced. Shorter detection windows reduce the cost of fixes: a defect caught in code review costs roughly 10× less to fix than one found in integration testing, and around 100× less than one found in production (per Capers Jones and Barry Boehm's independent research).

MTTD is calculated by averaging the gap between defect introduction time (when the faulty code was committed or deployed) and detection time (when the defect was first recorded). In practice, introduction time is often approximated from the commit that introduced the failing behaviour using git bisect or blame analysis.

Benchmarks are directional rather than absolute because MTTD conflates different detection stages — a defect caught by a unit test within minutes of commit has a vastly different MTTD to a defect found by exploratory testing two weeks after feature freeze. The 0–24 hour "fast" band generally corresponds to defects caught by automated tests in CI; the 24–168 hour "typical" band to defects caught in QA cycles; beyond 168 hours typically indicates production or UAT escapes.

Google's SRE Book and DORA research both identify short detection time as a key predictor of overall software delivery performance. Teams in the DORA Elite tier tend to have detection loops measured in hours, not days.

Use MTTD when you want to understand whether your feedback loops are tight. It is especially useful after introducing new automated testing or shifting testing left: you should see a measurable drop in average detection time if the change is working.

MTTD for production incidents is a different (and more urgent) measurement than MTTD for pre-release defects. Keep the two populations separate when calculating and reporting this metric.