Defect rate

How it is measured

Three common forms, in rough order of usefulness:

Escaped defect rate — defects found in production as a share of all defects found. Measures how much your pre-production checks actually catch.

Defects per change — defects attributable to a release or a pull request. Useful for correlating against things like pull request size, but attribution is often guesswork.

Defect count per period — the rawest form, and almost useless on its own, because it moves with how much you shipped. Ten bugs in a month of heavy delivery and ten in a quiet one are not the same result.

Why it is worth watching

Escaped defect rate is one of the few quality metrics that is not simply a restatement of a delivery metric. Nearly everything else on an engineering dashboard measures flow: how fast, how much, how long a queue. This measures whether the checks in that flow are doing anything.

It is also the natural counterweight to speed metrics. Cycle time can always be improved by reviewing less carefully and testing less thoroughly, and the bill for that arrives weeks later in a different report. Watching the two together is what stops a speed programme quietly turning into a quality problem.

What it misses

It measures your process, not your code. A team that finds more bugs may have better testing, not worse software. A falling total defect count is as easily a sign that people stopped looking as a sign that quality improved — which is why the escaped share is the more honest form.

Severity is invisible in a count. One outage that lost customer data and forty cosmetic misalignments are forty-one defects. Any team reporting a bare count is reporting mostly noise about its own triage habits.

Attribution is usually fiction. Tying a production bug back to the change that caused it is genuinely hard, and often the honest answer is an interaction between three changes and a config value. Per-change defect rates should be treated as directional at best.

Detection lags badly. Bugs shipped this month get found next month, or next quarter. A defect rate for a recent window is always incomplete, and always flattering.

How to read it well

Prefer the escaped share to any raw count. It normalises for volume and for how hard the team is looking, which are the two things that most distort the other forms.

Segment by severity before drawing any conclusion, and if you only track one thing, track the severe ones. A rising count of low-severity defects alongside a flat count of serious ones is usually a triage change, not a quality change.

Allow for the lag. Comparing this month against last month on a metric that takes six weeks to settle produces confident conclusions about noise. Use a trailing window wide enough that the recent end is not mostly missing.

And keep it next to a delivery metric, permanently. Defect rate read alone rewards shipping nothing, exactly as cycle time read alone rewards shipping anything. Neither is safe on its own dashboard.