Change Failure Rate
Change Failure Rate (CFR) measures the percentage of production deployments that result in a failure requiring remediation. It reflects how reliably teams ship changes and how often deployments trigger incidents, rollbacks, or hotfixes.
Calculation
This metric is calculated by dividing the number of failed deployments by the total number of deployments over a defined reporting window.
A failed deployment is typically defined as one that results in service degradation, a rollback, a user-facing bug, or an incident requiring emergency remediation. Teams should establish a consistent definition of failure that matches their operational reality to ensure accurate comparisons over time.
cfr = failed deployments ÷ total deployments × 100
Goals
CFR helps teams monitor the reliability of their release process and assess the risk associated with frequent deployments. It answers questions like:
- How often do changes we deploy introduce user-facing problems?
- Are our current validation and quality gates catching issues early enough?
- Is our delivery velocity undermining release stability?
Tracking CFR highlights whether the delivery process is producing predictable, safe outcomes or requiring frequent reactive fixes. For more background, see the DORA Metrics guide on Change Failure Rate.
Variations
CFR can be segmented to provide deeper insights:
- By environment, comparing failure rates across production and pre-production stages
- By deployment type, such as hotfixes versus planned releases
- By severity, including only failures that trigger incidents or customer-visible outages
Some teams also calculate median or percentile CFR over multiple windows to reduce skew from outlier events. Others tie failures to specific repos, teams, or service owners to identify where release risk is concentrated.
Limitations
CFR tells you how often things go wrong after release, but not why. It does not differentiate between small glitches and major outages, nor does it account for how quickly teams recover from incidents.
The metric can also be misleading if failure definitions are too broad or too narrow. For example, some teams count toggled-off features as success, while others count every production hotfix as failure, even when harmless.
To address these limitations, use CFR alongside the following metrics:
| Complementary Metric | Why It’s Relevant |
|---|---|
| Mean Time to Restore (MTTR) | Captures how quickly teams recover from deployment failures once they occur. |
| Deployment Frequency | Contextualizes how often deployments happen, which affects how CFR trends are interpreted. |
| Lead Time for Changes | Surfaces process delays that may limit validation time or increase delivery pressure. |
Optimization
Improving Change Failure Rate involves reducing the frequency of failure-triggering changes and minimizing the scope of their impact when they do occur.
-
Deploy smaller, safer changes. Reducing batch size lowers the likelihood of shipping defects and makes troubleshooting easier. Trunk-Based Development helps limit the blast radius of each deployment.
-
Catch problems earlier in the lifecycle. Strengthen pre-release validation with Test-Driven Development, integration testing, and staging parity. These reduce the number of defects that escape into production.
-
Enforce better review standards. Adopting consistent Code Review Best Practices ensures peer input before changes go live and improves the quality of merged code.
-
Use Feature Flags to reduce exposure. Flags enable teams to disable problematic functionality without rolling back the entire deployment. This limits failure impact and may prevent an issue from counting as a failed deployment.
-
Clarify what counts as a failure. Misalignment on what constitutes a “failed deployment” undermines tracking. Ensure failures are tagged consistently in incidents, deployment logs, or release notes.
Reducing CFR is not about achieving perfection. It’s about designing delivery systems that prevent failure when possible, and allowing teams to react quickly, learn, and improve when things go wrong.
