Change failure rate
The percentage of production deployments that require a hotfix or rollback — the primary DORA stability metric.
// Formula
// About this metric
Change failure rate measures the proportion of deployments to production that result in a service degradation, requiring a rollback, hotfix, or other remediation. It is one of the four DORA metrics and the primary measure of deployment stability and release quality.
The DORA 2024 classification places Elite teams at 0–5% change failure rate, High at 5–10%, Medium at 10–15%, and Low above 15%. A "failed change" is typically defined as a deployment that triggered an incident, required a rollback, required an out-of-band hotfix, or was associated with a significant customer-visible degradation.
Change failure rate and deployment frequency are the most important pair to watch together. DORA research consistently finds that Elite performers have both high deployment frequency and low change failure rate — disproving the intuition that deploying faster means deploying less safely. The mechanism is that smaller, more frequent changes are easier to test, review, and roll back than large, infrequent batches.
The causes of high change failure rate are usually: insufficient pre-deployment testing, lack of automated quality gates, large change batch sizes, or insufficient canary/feature-flag infrastructure to limit blast radius.
// Calculator
🧮 Calculator
Required rollback or hotfix
// Benchmark
Source: DORA State of DevOps Report 2024
// When to use this metric
Use change failure rate as your primary deployment quality metric. Monitor it per deployment and track the 30-day rolling average. Alert when it rises above your Elite/High threshold.
Review failed deployments as incidents rather than just statistics: understand whether the failure was caused by a testing gap, a deployment process gap, or an operational monitoring gap — the remediation differs significantly by root cause.
// Common pitfall
Change failure rate is easy to suppress by defining "failed change" narrowly — if only rollbacks count and hotfixes don't, you can push fixes for broken deployments without it registering. Define "failed change" broadly and consistently: any deployment that required out-of-band remediation within 24 hours counts, regardless of how it was remediated.