Metrics · Updated 2026-09-17
Change failure rate
The share of deployments that cause a degraded service — a rollback, a hotfix, an incident — one of the four DORA metrics.
Also called: CFR
What it is
Of the changes that reached production, what fraction caused a problem. It is the counterweight to deployment frequency: shipping more often only counts as improvement if this number holds.
Why it is the hardest of the four to measure honestly
It depends on a definition of “failure” that your team has to agree and then keep stable. Does a fast rollback count? A config fix within the hour? A degradation nobody outside engineering noticed? Teams that tighten or loosen this definition over time produce a trend that means nothing.
Attribution is the second problem. A deployment that fails because of a change three deploys earlier is not the failure of the change that revealed it.
Why review tooling claims here deserve scepticism
“Our tool reduces change failure rate” is the most common ROI claim in this category and the hardest to verify. Failures have many causes — test coverage, environment drift, dependency changes, load — and review is one input among them. A vendor case study showing a drop is showing correlation from a single team over a single window.
Treat it as a guardrail rather than a headline: watch that it does not get worse while you optimise for speed.
Common mistakes
- Redefining failure mid-measurement.
- Counting only incidents that triggered a page, which undercounts silent degradations.
- Expecting a review tool to move it measurably within a quarter.