Change Failure Rate

A product team deploys frequently but customers keep encountering faults after releases, and counting releases alone misses the risk. Change failure rate compares the deployments needing immediate repair with all relevant production deployments.

DORA defines change fail rate as the ratio of deployments requiring immediate intervention after deployment, often a rollback or hotfix. Google Cloud describes linking production deployments with incident records and notes that teams need clear definitions for their own data.

A failed test before production is not automatically a failed production change. Start by choosing the production service or application, because a combined company-wide number can hide one unstable service.

Define which deployments count in the denominator, since a tiny canary, a configuration rollout and a full release may be treated differently under a documented rule, and set a consistent rule for repeated deploys of the same version so retries do not distort the figure. Count qualifying failed deployments, not every user complaint, with each fault linked to a production change under the chosen criteria.

One deployment can trigger multiple incident tickets and should not be counted several times, while an incident from an unrelated vendor outage should not inflate the metric. As an illustration, 4 deployment-related failures among 40 production deployments produce a 10% change failure rate.

A low rate does not prove everything is healthy, since a team may barely deploy at all or miss incidents in its records, so review deployment frequency and recovery time alongside it. Choose a window long enough to give useful observations, because one failure in two releases can swing a weekly percentage sharply, and if there are zero deployments the rate is undefined for that period, not zero percent.

State whether releases are assigned by deployment date or incident discovery date, since delayed detection can change period totals, and link the deployment identifier to the incident or rollback record because human memory alone is a weak audit trail. Treat hotfixes carefully: a hotfix to repair the first release is an intervention, but the hotfix may itself also be a deployment.

Document whether unplanned emergency deployments count, since excluding them without a reason may make delivery look artificially stable, and do not confuse this metric with deployment rework rate, which DORA distinguishes as unplanned deployments resulting from production incidents rather than deployments that themselves need immediate intervention. Use the metric to learn, not to punish staff for reporting incidents, because fear of recording failures makes the number falsely reassuring, and post-incident reviews can improve classification.

A high rate may reveal fragile dependencies, poor testing data or weak rollback plans, so investigate examples rather than making a blanket claim, and severity can be added as context without redefining the core rate, since a brief internal issue and a long customer outage each count as one failed deployment under a simple numerator, and comparisons between services are misleading because release size, traffic and detection practices differ. Automated tests, smaller changes and staged rollout may reduce risk, but a manager should ask what failed, how users were affected and whether the process can catch that class of fault earlier.