Change failure rate

At a glance

DORA metric	What it measures	Improved badly by	Read together with
Deployment frequency	How often you ship to production	Batching changes into fewer releases	Change failure rate
Lead time for changes	Commit to running in production	Skipping review and testing	Change failure rate
Change failure rate	Share of deploys needing remediation	Deploying less often	Deployment frequency
Time to restore service	How long degradation lasts	Rolling back without diagnosing	Change failure rate
Rework rate	Share of work that is unplanned fixing	Reclassifying fixes as features	All four

How it works

Change failure rate is a ratio: deployments that caused a problem, divided by deployments made, over a window. Its value comes from being the counterweight in a set of four metrics that are each trivially gameable alone.

Deployment frequency and lead time push towards shipping faster. Left unbalanced, a team can improve both by removing the checks that make shipping safe. Change failure rate is the metric that notices, which is why DORA treats speed and stability as a pair rather than a trade-off to be chosen between. The consistent finding across DORA's research has been that high performers do well on both at once, because the practices that make deployment fast, small batches, automation, fast rollback, are the same practices that make it safe.

The definition of a failure needs settling before the number means anything. The workable version is a deployment leading to degraded service that required remediation: a rollback, a hotfix, an emergency forward fix, or a declared incident. A change reverted because product changed its mind is not a failure. A change that degraded latency for a week without being attributed to a deploy is a failure your measurement will miss.

That attribution problem is the practical difficulty. Linking a degradation back to the specific change that caused it is exactly the diagnosis work an incident requires, and where that is slow or unreliable, change failure rate is under-reported in proportion to how hard the failures are to trace. The metric is therefore partly a measurement of your own diagnostic capability, which is worth knowing when comparing it to anyone else's.

The denominator matters as much. A team where one deployment carries thirty commits will show a different rate from one deploying each commit separately, even with identical underlying quality.

How it is measured

Take deployments from the deployment system rather than from a spreadsheet, and count every production deployment, including the ones nobody thought were risky. Excluding routine deploys inflates the rate and removes the comparison's meaning.

Attribute failures automatically where you can. If the link between an incident and a deploy is made by hand during a retrospective, the failures that were easy to trace will be recorded and the subtle ones will not, which biases the number towards optimism precisely where you most want the truth.

Use a window long enough to be stable. Teams deploying a few times a week need a quarter before the rate means much, since a single bad week dominates a monthly figure.

Segment by service. An organisation-wide rate averages together a well-tested core service and a fragile edge one, and the average describes neither. The per-service split is what turns the metric into a decision about where to invest in testing or staged rollout.

Always publish it next to deployment frequency. What the DORA metrics measure covers the full set, and the pairing is the point: a rate of 5% at one deploy a month and a rate of 12% at forty deploys a week describe two very different organisations, and the second is usually the healthier one.

Common misconceptions

That a lower rate is always better. It can fall because quality improved, or because the team started batching changes into fewer, larger, riskier releases. The number alone does not distinguish these, and the second is a regression.

That it measures individual carelessness. It mostly measures the safety net around the path to production. Thin test coverage, no canary or staged rollout, and slow rollback all raise it regardless of who is deploying.

That failures are always visible immediately. Slow degradations and changes that only fail under specific conditions are systematically undercounted, which means the true rate is usually somewhat higher than the measured one.

That industry benchmarks are directly comparable. The definition of both a deployment and a failure varies enough between organisations that cross-company comparison is weak. Your own trend is the useful signal.

That it is a reliability metric on its own. It says how often changes hurt, not how much. A team with a moderate rate and fast recovery is often in better shape than one with a low rate and hours of impact when it happens. How mean time to resolution is measured covers the other half.