What Is Change Failure Rate?
Change failure rate is a DORA stability metric: the percentage of deployments to production that result in a failure requiring remediation, such as a rollback, hotfix, or incident.
Change failure rate balances the speed metrics by asking a quality question: of all the changes you ship, how many go wrong? Tracking it keeps teams honest about whether they are shipping fast or just shipping recklessly.
What counts as a failure
A change failure is a deployment that degrades service and needs a response -- a rollback, a hotfix, a patch, or an incident. The exact definition matters less than applying it consistently, so the metric trends meaningfully over time rather than swinging with interpretation.
How it is calculated
Change failure rate is the number of failed deployments divided by the total number of deployments, expressed as a percentage. It is a rate, not a count, which means a team that deploys frequently is not penalized simply for shipping more -- only for a higher proportion going wrong.
Why it pairs with speed
On its own, deploying often or quickly could just mean breaking things faster. Change failure rate is the counterweight: it ensures that gains in throughput are not coming at the expense of quality. Elite teams keep this rate low even while deploying constantly.
Driving it down
Lower change failure rates come from smaller changes, strong automated testing, good code review, and progressive delivery techniques that limit blast radius. Reliable CI matters too: if test results are noisy or flaky, real regressions slip through and bad changes reach production.
Interpreting the number
A very low change failure rate can be healthy, but a near-zero rate sometimes signals excessive caution and slow delivery. Read it alongside deployment frequency and lead time to confirm you are achieving stability and speed, rather than buying one with the other.
Key takeaways
- Change failure rate is the share of deployments that cause a failure needing remediation.
- As a rate, it does not penalize teams simply for deploying more often.
- Smaller changes, solid testing, and progressive delivery push it down.