Back to Process metrics
⚙️ Process

Change failure rate

The percentage of production deployments that require a hotfix or rollback — the primary DORA stability metric.

processdorafailure-rate

// Formula

failed deployments÷total deployments×100%

// 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

Your change failure rate8.0%

// Benchmark

You're in the DORA 'High' tier — 8.00 % puts you between 5.00 and 10.0 % (2024 State of DevOps Report).

// 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.