Change failure rate

Change failure rate is the percentage of deployments to production that degrade service and require immediate remediation — a rollback, hotfix, or patch — instead of working as released.

It is one of the five DORA metrics, where DORA calls it change fail rate. DORA's current phrasing is "the ratio of deployments that require immediate intervention following a deployment" (dora.dev, as of 2026-07-28).

How it is measured

Change failure rate = remediated deployments divided by total deployments over a window. The catch is that the numerator lives in production, not in CI. Pipeline data shows red and green runs; it cannot see a deploy that passed CI and broke production an hour later, a rollback that bypassed the pipeline, or how severe an incident was.

What CI data alone does give you is a usable leading proxy: the failure rate of the deploy pipeline (or the default branch) computed over decisive runs. Every red deploy run is a change that failed before or while shipping, so a CI-derived figure is a lower bound on instability — honest tooling labels it a proxy, not a true change failure rate. See also pipeline success rate.

What counts as good

The 2024 DORA report clustered change failure rate so that the High band sat above the Medium band — a fair warning against reading the raw figure as a ranking. Exact percentages appear only inside the downloadable report; the landing page itself publishes no benchmark table (checked 2026-07-28). DORA's 2025 report groups teams into seven common team profiles or archetypes instead, and DORA's current software delivery performance metrics guide publishes no elite/high/medium/low bands at all — so content still promising an "elite threshold" is quoting a benchmark DORA no longer publishes.

Context matters more than the raw figure. A team deploying fifty times a day at 5% causes more production incidents than a team deploying weekly at 15%, and all DORA figures are self-reported survey data, not telemetry. The practical target is a trend: a falling rate on your own deploys beats any point-in-time comparison against someone else's survey answers.

Why it matters

Change failure rate is the counterweight to throughput. Deployment frequency and change lead time reward shipping fast; this metric checks whether fast shipping actually holds up in production. Watched alone, it also invites gaming — a team can lower it by deploying less, which is exactly the failure mode the balanced DORA set exists to catch.

TrimCI computes the CI-side view of this metric in its PDF reports: a single main-branch failure rate over decisive runs across the report's repository scope, deliberately labeled a DORA-lite proxy — with the production-visibility limits above stated rather than glossed over. (TrimCI identifies the main branch by name — main or master — not from a stored default-branch setting, so repos using another name land on the other-branches side.)