Guide
Change failure rate
Change failure rate is the proportion of deployments to production that cause a degradation requiring remediation — a hotfix, a rollback or a patch. It is a quality measure of the delivery process rather than of the code, and it is defined by the response a problem required, not by the existence of a bug.
The definition does the work
Nearly every argument about this metric is really a definitional argument. A defect discovered in production three months later, in a feature nobody uses, that gets fixed in the next ordinary sprint, is not a change failure. A deployment that required an out-of-band fix that evening is.
The distinguishing test is whether the change required remediation outside the normal flow of work. That keeps the metric about the delivery process — did what we shipped work — rather than about total defect count, which is a different measure with a different denominator and different causes.
Calculating it without incident tooling
Most organisations do not have clean incident data, and waiting until they do means never measuring this. The practical route is to identify remediation work in the systems you already have: hotfix branches, revert commits, defect issue types linked to a recent release, or a specific label your team already applies.
The important discipline is that these definitions have to be explicit and confirmed by someone who knows the process. On a real Jira site we connected, the issue type that appeared to mean "defect" turned out to be an Xray link type; the genuine defect issue types were Bug and Bug (sub-task), and one resolution — Irreproducible — meant the defect was not real at all. A tool that guessed would have reported a confident and completely wrong figure.
Where those definitions are missing, the honest output is "not configured", not zero. A change failure rate of 0% is one of the least believable numbers an engineering organisation can present, and it will be the first thing challenged.
What moves it
Smaller changes, deployed more often, fail less — the same finding that connects the throughput and stability halves of DORA. Beyond batch size, the reliable levers are automated testing that people actually trust, a review process that catches design problems rather than formatting, and a rollback path that has been used recently enough to know it works.
What does not move it is a heavier approval process. The DORA research is fairly pointed on this: change advisory boards correlate with worse performance on both throughput and stability.
Where this measure goes wrong
Each of these produces a number that looks reasonable and is not.
Counting every bug
This measures defect volume, not delivery quality, and produces a figure so high it gets dismissed.
Reporting zero because nothing is configured
An unconfigured metric should say so. A confident zero is worse than a visible gap because nobody investigates it.
Guessing at what a defect issue type is called
Every issue tracker has its own vocabulary. "Defect" may not be an issue type at all on your site.
Comparing across teams with different definitions
If two teams classify remediation differently, their failure rates are not comparable and the comparison will be used anyway.
Frequently asked questions
What is a good change failure rate?
Roughly 5% is elite by DORA’s banding, around 10% high and around 15% medium. The exact thresholds shift between annual reports. A rate under 5% on a large sample is worth checking rather than celebrating — it usually means remediation work is not being captured.
Is change failure rate the same as defect rate?
No. Defect rate counts bugs found. Change failure rate counts deployments that needed remediation. A team can have many minor defects and a low change failure rate, and that combination is entirely healthy.
Do we need incident management tooling to measure it?
It helps, but it is not required. Most organisations can identify remediation work from hotfix patterns, revert commits or defect issues linked to a release. What is required is that the definition is explicit rather than assumed.
See change failure rate for your own teams
Pacia computes this from your repositories and issue tracker, banded and trended, with a drill-down to the work behind every figure.