What is change failure rate?

What change failure rate measures

Change failure rate is a stability metric. Where deployment frequency and lead time describe how fast a team moves, CFR describes how safely. It captures the fraction of deployments that degrade service and require an unplanned response — the changes that had to be corrected rather than the ones that landed cleanly.

The critical definitional point is what counts as a failure. DORA scopes it to changes that result in degraded service and require remediation: a rollback, a forward fix, a hotfix, or a patch. A failure caught in a pre-production test or staging environment does not count — CFR is about changes that reach production and cause a problem there. Bugs found before release are the pipeline working, not a change failure.

• Counts: a deployment that triggers a rollback, hotfix, patch, or fix-forward in production.
• Counts: a release that causes an outage, degradation, or incident requiring an unplanned response.
• Does not count: a defect caught in testing or staging before it reaches production.
• Does not count: planned follow-up work or a routine subsequent deployment with no failure.

How to calculate change failure rate

The calculation is the number of deployments that caused a failure divided by the total number of deployments in a period, expressed as a percentage. If a team made 40 production deployments in a month and 4 of them required a hotfix or rollback, change failure rate is 10 percent.

The denominator matters as much as the numerator. CFR is a rate over deployments, not over calendar time, which is why it stays comparable as deployment frequency rises. A team that deploys ten times as often is not expected to have ten times the failures — holding CFR steady while frequency climbs is exactly the trade-off the metric is designed to surface.

Why CFR balances the speed metrics

DORA's four metrics are meant to be read as a set precisely so no single dimension can be optimized at the expense of the others. Deployment frequency and lead time reward speed; change failure rate and time to restore guard quality and resilience. Push only on speed and CFR tends to rise; over-index on avoiding all failure and speed collapses. The signal to watch for is throughput increasing while failure rate holds or falls.

This balance is why CFR should never be presented alone. A low change failure rate achieved by shipping rarely is not a strong result, and a slightly higher CFR on a team deploying continuously may be perfectly healthy. The metric earns its meaning only in the context of the other three.

Common pitfalls

The most common problem is an inconsistent definition of failure. If one team counts every customer-reported bug and another counts only outages, their change failure rates cannot be compared. Agree on what remediation qualifies — and apply it uniformly — before comparing numbers across teams or over time.

CFR is also gameable in ways that look like improvement but are not. Bundling many changes into one large, infrequent release lowers the count of failing deployments while raising the blast radius of each. Reclassifying incidents as routine follow-ups hides failures. Because these tactics improve the metric while worsening the underlying system, CFR should always be read alongside deployment frequency and time to restore, never as a standalone target.

Frequently asked questions