Defect Escape Rate: The Formula, the Benchmarks, and How to Measure It
Updated June 2026
Defect escape rate, in one line
Defect escape rate is the share of all defects that reach production instead of being caught before release. Divide the defects found in production by the total defects found in the same period, then multiply by 100. Elite teams stay under 5%; 12 to 18% is typical.
The formula
DER = (defects found in production / total defects found) x 100The denominator is every defect found in the period: the pre-release ones caught by tests, review, and QA, plus the ones that escaped to production. Defect escape rate is the exact complement of Defect Removal Efficiency (DRE): DER = 100% minus DRE.
Defect escape rate answers one question: of all the bugs your process found, how many did it fail to catch before your users did? It is the single clearest measure of how well a team's pre-release detection is working, because escaped defects are the most expensive class of rework. A defect caught in code review costs an hour; the same defect caught in production drags in incident response, a hotfix, customer support, and reputation, often 10 to 100 times the internal cost per the Boehm cost-of-change curve.
The metric is also known as defect leakage. The two terms are interchangeable: defect leakage is the older QA framing (defects leaking past a test phase), defect escape rate frames the same thing around production as the boundary. Both are the inverse of Defect Removal Efficiency, the metric Capers Jones popularised in Applied Software Measurement.
Defect escape rate benchmarks
These bands are the inverse of Capers Jones's Defect Removal Efficiency data. A US-average DRE of about 85% implies a defect escape rate near 15%; best-in-class DRE above 95% implies an escape rate under 5%.
| Band | Defect escape rate | Equivalent DRE | What it means |
|---|---|---|---|
| Elite | Under 5% | 95%+ DRE | Multiple detection layers: unit + integration tests, code review, static analysis, and QA. Jones: topping 95% DRE needs pre-test inspection, not testing alone. |
| Average commercial | 12 to 18% | ~85% DRE | The US-average band. Defects are caught, but a meaningful share still reaches users and turns into the most expensive class of rework. |
| Worst quartile | Over 35% | Under 65% DRE | Testing is happening too late in the cycle. Jones: projects below 85% DRE run late, run over budget, and rarely have happy customers. |
Source: Capers Jones, Applied Software Measurement (3rd ed., 2008) and Software Defect Removal Efficiency. Jones notes that DRE above 95% cannot be reached by testing alone; it requires pre-test inspections and static analysis.
Worked example
A team ships a quarter of work and logs every defect by where it was found:
- Unit and integration tests caught 140 defects
- Code review and QA caught 36 defects
- Production incidents and customer reports surfaced 24 defects
Total defects found: 140 + 36 + 24 = 200. Defects that escaped to production: 24.
DER = 24 / 200 x 100 = 12%A 12% escape rate (88% DRE) sits at the better edge of the average band. To move into the elite band under 5%, the team needs to shift detection earlier, because the 24 escaped defects are the ones generating the bulk of the rework cost.
The numbers above are an illustrative example, not benchmark data.
How to measure it in Jira
The metric only works if every bug is tagged by where it was found. Label production-reported bugs, then count them against the total. This JQL returns the numerator (escaped defects) for the last 90 days:
issuetype = Bug
AND labels in (production, escaped, customer-reported)
AND created >= -90dRun the same query without the labels filter to get the denominator (all bugs found in the period), then divide. The measurement guide has the full set of Jira JQL and Linear queries for rework ratio, change failure rate, and defect escape rate; the benchmarks page puts your number next to the DORA and Capers Jones tiers.
The measurement trap
The most common mistake is leaving pre-release defects out of the denominator. If you only count bugs that have a ticket, and your QA team fixes issues informally without logging them, the denominator collapses and the escape rate looks far worse than reality, or the opposite if production bugs go untracked. Defect escape rate is only trustworthy when both halves are counted the same way: every defect, wherever it was found, gets a record. It is a ratio of two counts from the same funnel, not an absolute bug count.
Frequently Asked Questions
How do you calculate defect escape rate?▼
DER = (defects found in production / total defects found) x 100. The denominator is every defect found in a period, both the pre-release ones caught by tests, review, and QA and the ones that escaped to production. If a cycle finds 200 defects and 24 came from production, the defect escape rate is 24 / 200 = 12%.
What is a good defect escape rate?▼
Elite teams stay under 5% (more than 95% of defects caught before release). Around 12 to 18% is typical for average commercial software; a worst-quartile rate above 35% signals that testing is happening too late. These bands are the inverse of Capers Jones's Defect Removal Efficiency: US-average DRE of about 85% implies an escape rate near 15%.
What is the difference between defect escape rate and defect leakage?▼
They are the same metric under two names. Defect leakage is the older QA term for defects leaking past a testing phase; defect escape rate frames the same idea around production as the boundary. Both measure the share of defects not caught before they reached users. Defect Removal Efficiency (DRE) is the exact complement: DER = 100% minus DRE.
What is the industry standard defect escape rate?▼
There is no single mandated standard, but the most cited benchmark is Capers Jones's: US-average DRE is about 85%, putting the average defect escape rate near 15%. Best-in-class projects exceed 95% DRE (escape rate under 5%), and Jones notes that topping 95% DRE requires pre-test inspections and static analysis, not testing alone.
How do you measure defect escape rate in Jira?▼
Tag production-reported bugs with a label such as production, escaped, or customer-reported. Count them (issuetype = Bug AND labels in (production, escaped, customer-reported) AND created >= -90d) for the numerator; run the same query without the labels filter for the denominator, then divide and multiply by 100.
Continue reading:
How to Measure Rework
Jira JQL + Linear queries for the four metrics that matter
Benchmarks 2026
Compare your escape rate to DORA + Capers Jones tiers
Testing & Defect-Removal Effort
Why defect removal is software's largest single cost
Boehm Cost of Change Curve
Why an escaped defect costs 10-100x the caught one
Sources
- Jones, C. Applied Software Measurement. 3rd ed. McGraw-Hill, 2008. (Defect Removal Efficiency benchmarks: US average ~85%, best-in-class 95%+)
- Jones, C. Software Defect Removal Efficiency. (95%+ DRE requires pre-test inspection and static analysis, not testing alone)
- Google DORA. State of DevOps Report 2024. (Change failure rate tiers: elite under 5%)