Defect escape rate
The percentage of defects not caught before release — the most direct measure of testing effectiveness.
// Formula
// About this metric
Defect escape rate measures how many defects slipped through your testing process and reached production. A defect is "escaped" if it was found by a user, on-call engineer, or monitoring system rather than during pre-release testing. The formula is: production defects divided by total defects found (pre-release plus production), expressed as a percentage.
This metric is one of the most direct signals of testing effectiveness available. A team that ships 100 defects but catches 95 before release has a 5% escape rate — significantly better than a team that ships 20 defects but lets 4 reach production (20% escape rate).
The World Quality Report (Capgemini/Sogeti, 2024–25) places industry average escape rates at 5–15%, with leading teams achieving under 5%. This benchmark assumes consistent defect classification — the same types of issues are being counted in both numerator and denominator.
Escape rate is most valuable when paired with severity data. A 3% escape rate where all escaped defects are critical is a worse outcome than a 10% escape rate where all escaped defects are trivial. Severity-weighted escape rate is more informative than raw escape rate alone.
// Calculator
🧮 Calculator
Pre-release + production
// Benchmark
Source: World Quality Report 2024-25, Capgemini/Sogeti
// When to use this metric
Use defect escape rate to evaluate your testing process end-to-end. It is the answer to "is our testing actually working?" and is a useful input for release-readiness decisions and post-release retrospectives.
It requires reliable production defect tracking — if your team doesn't consistently log production issues in the same system as pre-release defects, the denominator will be incomplete and the metric will be misleadingly low.
// Common pitfall
The escape rate drops to zero if you stop logging production defects, not because quality improved. Teams under pressure to improve the number have been known to reclassify production incidents as "deployment issues", "infrastructure bugs", or "feature requests" rather than defects. Watch the production bug backlog volume as a sanity check on the denominator.