Engineering & Reliability

Change Failure Rate CFR

CTO VP Engineering Director Engineering

Change Failure Rate (CFR) measures the percentage of deployments or changes to production that result in a service degradation, incident, or rollback. It is one of the four DORA metrics and reflects the stability of the software delivery process. A low CFR indicates that the team's testing, review, and deployment processes are effective at catching problems before they reach production.

CFR should be evaluated alongside deployment frequency; a team with zero CFR might simply be deploying infrequently, not deploying safely.

Formula

Number of Failed Deployments ÷ Total Number of Deployments × 100

Where It Lives

GitHub ActionsDeployment success and failure tracking in CI/CD pipelines
DatadogDeployment change markers correlated with error rate spikes
PagerDutyIncidents triggered by deployment events
LinearBDORA metrics including CFR by team and time period

What Drives It

Test coverage quality and completeness in CI pipeline
Code review rigor and PR review standards
Deployment size (larger changes have higher CFR)
Feature flag usage to isolate risk of new code
Pre-production environment parity with production

Benchmark

DORA elite teams target CFR of 0%–15%; high performers 0%–15%; medium performers 16%–30%; low performers above 45%.

Common Questions About Change Failure Rate

What is a good change failure rate to target?

DORA research defines elite teams as those with CFR between 0% and 15%. A CFR above 30% indicates serious problems in the testing or deployment process. However, context matters: teams experimenting with new architecture or technologies may temporarily accept higher CFR while learning. The key is that CFR should be tracked, understood, and improving over time.

How do small batch sizes reduce change failure rate?

Smaller deployments are inherently lower-risk because they contain fewer changes, making it easier to identify which change caused a problem and to roll back only that change without affecting other work. Large batch releases combine many changes, making debugging harder, rollback more destructive, and the blast radius of any single bug larger. Trunk-based development and continuous integration enforce small batch sizes as a reliability practice.

What is the relationship between CFR and MTTR?

CFR determines how often recovery is needed; MTTR determines how long each recovery takes. A team with high CFR but very low MTTR (e.g., automated rollback in minutes) may have acceptable overall reliability. A team with low CFR but high MTTR (rare failures but very slow recovery) may also be acceptable depending on their uptime SLO. The two metrics together define the reliability profile: how often things break and how quickly they are fixed.

How can I reduce CFR without slowing deployment velocity?

Invest in automated testing (unit, integration, end-to-end) that runs in the CI pipeline and blocks bad code before deployment. Use feature flags to decouple risky code deployment from user-facing release. Implement canary deployments that gradually roll out changes to a small percentage of users before full rollout. Add deployment-correlated monitoring that automatically rolls back if key metrics degrade following a deployment.

Related Metrics

Deployment Frequency | Deployment Frequency MTTR | Mean Time to Recovery LTFC | Lead Time for Changes SLA% | System Uptime / Availability

free, one business day

Want to know what is holding your Change Failure Rate back?

Give us your website and we will send back the specific pages hurting your Change Failure Rate, in the order worth fixing. You will have it within one business day, free, with no obligation.