SEO from $300/mo AI-powered, human-verified No agency markup Transparent platform included
/// 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
Causal Analysis: Correlating CFR with deployment size, deployment time, and code complexity helps identify the specific change characteristics that causally increase failure probability.
Benchmark

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

Common Mistake
Counting only complete outages as failures and excluding partial degradations, service slowdowns, and features that shipped with bugs requiring hotfixes within 24 hours.

How Different Roles Think About This Metric

Each function reads CFR through a different lens and takes different actions when it changes.

CTO
The CTO monitors CFR alongside deployment frequency to assess whether the team is achieving sustainable velocity or trading speed for stability.
VP Engineering
VP Engineering uses CFR to evaluate test automation quality and deployment process maturity across engineering teams.
Director Engineering
Directors investigate high CFR events to identify root causes and implement process improvements in testing, review, or deployment procedures.

Common Questions About Change Failure Rate

Click any question to expand the answer.

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

Metrics that are commonly analyzed alongside CFR.

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

Role Guides That Include This Metric

See how each role uses CFR in context with the full set of metrics they own.

CTO Guide → VP Engineering Guide → Director Engineering Guide →
/// get started

See What’s Actually Moving Your CFR

askotter connects your data sources and applies causal analysis to tell you exactly why your metrics are changing, not just that they changed.

Book a Conversation →