Change failure rate is the percentage of deployments to production that cause a failure requiring immediate remediation — a hotfix, a rollback, a patch, or a forward fix. It is one of the four DORA keys, and it is the one that keeps the other three honest: without it, a team can look elite simply by shipping fast and breaking things.

How do you calculate change failure rate?

Divide failed deployments by total deployments over the same window, then multiply by 100.

Change failure rate = (failed deployments ÷ total deployments) × 100

If you shipped 80 deployments last month and 6 of them required a hotfix or rollback, your change failure rate is 7.5%. That is the whole calculation. The arithmetic is trivial; the definitions underneath it are not, which is where most measurement programs quietly go wrong.

What is a good change failure rate?

The benchmark tightened considerably. For years the widely-quoted elite band was 0–15%. DORA’s 2025 research puts top-tier performance at 0–2%, and only a small minority of teams — under 10% of respondents — actually clear that bar. If you have been reporting “under 15%, so we’re elite” against an older chart, that claim no longer holds.

There is a second, larger change worth knowing about: DORA’s 2025 report retired the familiar low / medium / high / elite clusters altogether, replacing them with seven team archetypes defined by delivery performance and human factors such as burnout and organizational friction. The practical consequence is that a single percentage no longer earns you a tier label. Change failure rate is still worth tracking — it just answers “is our delivery stable?” rather than “what rank are we?”

A more useful internal target than any published band: your own trend. A rate that is flat or falling while deployment frequency rises is the signal that matters. A rate that climbs as you ship more means your delivery speed is being financed by instability.

The hard part: what counts as a failure?

Two teams with identical engineering quality can report a 2% and a 20% change failure rate purely by defining “failure” differently. Before you publish a number, settle these four questions and write the answers down:

• Does a failure require user impact? A rollback caught by monitoring before any customer noticed is still a failed change under DORA’s definition — the deployment did not succeed. Teams that count only customer-visible incidents systematically under-report.
• Is the unit a deployment or a change? If you batch twelve merges into one release and it fails, is that one failure or twelve? DORA counts deployments. Batching therefore flatters the metric — another reason to read it alongside deployment frequency.
• Does a config or feature-flag change count? If flipping a flag can take production down, it is a change to production. Excluding flags is a common and convenient blind spot.
• What is the time boundary? A defect found three weeks later is usually escaped-defect territory, not change failure rate. Most teams draw the line at remediation triggered by that deployment, typically within hours to a day.

None of these has a universally correct answer. What matters is that the definition is explicit, stable over time, and stated whenever the number is presented. A change failure rate quoted without its definition is not a measurement.

Measuring change failure rate when the record lives in Jira

Change failure rate is a deployment-pipeline metric, so its cleanest source is your CI/CD system. But for many teams the evidence of failure — the incident, the hotfix ticket, the rollback decision — is recorded in Jira, not in the pipeline. That makes Jira a legitimate measurement surface, with one condition: the failure signal has to be structured rather than inferred from prose.

A workable setup looks like this:

• A dedicated issue type or label for remediation work (hotfix, rollback, incident) applied consistently — this becomes your failure numerator.
• A link from each remediation issue back to the release or deployment that caused it, so failures attribute to the right window.
• A reliable count of total deployments per period, usually from the pipeline or from Jira releases if every release maps to one deployment.
• An agreed review cadence, because the metric drifts the moment labelling discipline slips.

The realistic caveat: if deployments are not represented in Jira at all, Jira can give you the numerator but not a trustworthy denominator, and you will need the pipeline for the total. Be honest about which half you actually have before publishing a percentage to leadership.

Read it against the other keys, never alone

Change failure rate is a ratio, and ratios are easy to game. Deploy once a quarter and your rate will look superb. The metric only means something in tension with the throughput keys — which is why DORA treats the four as a set rather than a scoreboard.

Pair it with lead time for changes to see whether stability is costing you speed, and with cycle time vs. lead time to work out where in the flow the delay actually sits. For how all four keys fit together, and where Jira can and cannot supply the data, start with our complete guide to DORA metrics in Jira.

If you are measuring flow in Jira today, Time in Status, Cycle Time & Lead Time Reports covers time in status, cycle time, lead time and throughput out of the box. The four DORA keys, including change failure rate, are on our roadmap rather than shipped today — this guide is about the measurement discipline, which is worth getting right regardless of tooling.

Frequently asked questions

What is an acceptable change failure rate?

Under DORA’s 2025 research, 0–2% represents top-tier stability, and most teams sit well above it. Rather than chasing a published band, treat anything that is stable or falling while your deployment frequency rises as acceptable, and investigate any sustained upward trend.

Is change failure rate the same as defect rate?

No. Defect rate counts bugs found anywhere, at any time, including in work that never shipped. Change failure rate counts only deployments to production that had to be remediated. A team can have many open defects and a low change failure rate, or very few defects and a high one if its releases are large and risky.

What is the formula for change failure rate?

Failed deployments divided by total deployments in the same period, multiplied by 100. Both terms must cover the identical window, and “failed” must mean the same thing every time you report it.

How is change failure rate different from mean time to recovery?

Change failure rate measures how often deployments break production. Mean time to recovery measures how long you take to fix it once they do. The pair answers two separate questions — frequency and severity of impact — and a team can be strong on one while weak on the other.