# Change fail rate

> **Note:** New to DORA? Start with [What is DORA?](/docs/engineering-delivery/what-is-dora), a five minute introduction that assumes no prior knowledge.

Change fail rate is the share of your deployments that go wrong and need fixing straight away. It is one of the five DORA metrics, sometimes called change failure rate, and it tells you how often shipping a change causes trouble for your users.

## What is change fail rate?

DORA defines it as:

> "The ratio of deployments that require immediate intervention following a deployment."

The 2025 DORA report adds that such a deployment is "likely resulting in a rollback of the changes or a 'hotfix' to quickly remediate any issues" (2025 report, p.13).

In plain words: out of all the times you put a change live, how many times did you have to rush in and fix it? The two usual ways of fixing it are:

- a [rollback](/docs/engineering-delivery/glossary#rollback), which undoes the deployment and puts the previous version back, or
- a [hotfix](/docs/engineering-delivery/glossary#hotfix), a quick extra change made only to repair what broke.

Our example team of six building an online booking app deployed 40 times last month. Three of those deployments broke something for users: one stopped confirmation emails, one showed the wrong prices in one currency, and one slowed the search page so much they rolled it back. Their change fail rate is 3 out of 40, which is 7.5%.

Change fail rate is one of DORA's two **instability** metrics, the ones that describe how well deployments go. The other is [deployment rework rate](/docs/engineering-delivery/deployment-rework-rate). Together, DORA says, they measure "the likelihood deployments unintentionally lead to immediate, additional work" (2024 report, p.12).

## Why does it matter?

- **Failures cost twice.** A broken deployment costs the time to fix it, and the trust of the users who ran into the problem.
- **It balances speed.** Deploying often is only good if deployments mostly work. Change fail rate is the check on the throughput metrics, such as [deployment frequency](/docs/engineering-delivery/deployment-frequency).
- **It points at weak spots.** A rising fail rate often means changes are getting bigger, tests are missing something, or one part of the system is fragile.

Speed and stability are not a trade-off you are forced to make. The 2025 report calls the "speed vs. stability" trade-off "a myth": the best performing groups do well at both at once (2025 report, p.19).

## How do you measure it?

Divide the number of deployments that needed immediate intervention by the total number of deployments to production, over the same period.

The hard part is deciding what counts as a failure. DORA's own rule is a good one to adopt:

> "We consider a deployment to be a change failure only if it causes an issue after landing in production, where it can be experienced by end users. In contrast, a change that is stopped on its way to production is a successful demonstration of the deployment process's ability to detect errors." (2024 report, p.16)

So:

- **A test that catches a bug before release is not a failure.** It is your safety net working.
- **A deployment that is rolled back because users hit a problem is a failure.**
- **A deployment followed by a hotfix for the same problem is a failure.**
- **A planned follow-up change is not a failure.** Shipping step two of a feature the next day was always the plan.

Where does the data come from? Rollbacks and hotfixes usually show up in your deployment history (a redeploy of an older version, or a change labelled as a hotfix). An [incident](/docs/engineering-delivery/glossary#incident) tool, where you record outages and their causes, can confirm which deployments caused problems.

> **Tip:** Write down your rule for what counts as a failure and keep it stable. If the rule changes, the number changes, and you can no longer compare this month with last.

## Change fail rate by service

DORA asks you to use these measures "in the context of the application or service your team is delivering" and to apply them one application or service at a time (DORA metrics guide). This matters most for change fail rate.

Imagine the booking app team owns three [services](/docs/engineering-delivery/glossary#service): the website, the payments service and the email service. Over a month:

| Service | Deployments | Needed a fix | Change fail rate |
| --- | --- | --- | --- |
| Website | 30 | 1 | 3% |
| Payments | 6 | 2 | 33% |
| Email | 4 | 0 | 0% |
| **Team total** | **40** | **3** | **7.5%** |

The team total of 7.5% looks healthy. But one deployment in three to the payments service went wrong. A single team number hides the one service that carries most of the risk. Look per service, start with the highest, and look at what its failed deployments had in common.

Two cautions when you read per service numbers:

- **Small counts swing wildly.** A service with four deployments jumps from 0% to 25% with one failure. Always look at how many deployments a rate rests on.
- **Do not use it to compare teams.** Services differ in age, risk and complexity. DORA warns against "making disparate comparisons" (DORA metrics guide). Compare each service with its own past.

## What does good look like?

The 2024 DORA report found four performance levels (2024 report, p.13):

| Level | Change fail rate | Share of respondents |
| --- | --- | --- |
| Elite | 5% | 19% |
| High | 20% | 22% |
| Medium | 10% | 35% |
| Low | 40% | 25% |

You may notice that medium performers had a lower fail rate than high performers. That is not a typo. DORA explains that it chose to call the faster teams "high" and the slower but more stable teams "medium", and that this "highlights one of the potential pitfalls of using these performance levels: Improving should be more important to a team than reaching a particular performance level" (2024 report, p.14).

The 2025 report shows how all respondents answered (2025 report, p.21):

| Change fail rate | Share of respondents |
| --- | --- |
| 0% to 2% | 8.5% |
| 2% to 4% | 8.1% |
| 4% to 8% | 19.6% |
| 8% to 16% | 26% |
| 16% to 32% | 19.5% |
| 32% to 64% | 12.5% |
| More than 64% | 5.9% |

The most common answer was 8% to 16%, and 62.2% of respondents reported 16% or less.

Treat these as context, not a target. Compare a service with its own past, and see [DORA performance levels](/docs/engineering-delivery/performance-levels#the-2024-performance-levels) for how to use benchmarks well.

## How do you improve it?

1. **Look per service first.** Find the service with the highest rate and focus there.
2. **Review recent failures together.** Take the last few deployments that needed a fix and ask, without blame: what did they have in common? Size, a missing test, a risky area of code, a configuration change?
3. **Add a check for the last failure you saw.** Every failure is a test you did not have yet. [Test automation](https://dora.dev/capabilities/test-automation/) and [continuous integration](https://dora.dev/capabilities/continuous-integration/) stop the same problem twice.
4. **Ship smaller changes.** Smaller changes are easier to review and less likely to break. When they do break, the cause is easier to find. See [Change size](/docs/engineering-delivery/review#change-size) and DORA's [working in small batches](https://dora.dev/capabilities/working-in-small-batches/).
5. **Make sure changes get a real review.** A change nobody else read is a change nobody else checked. See [Changes merged without review](/docs/engineering-delivery/review#changes-merged-without-review).
6. **Watch production closely.** Good [monitoring and observability](https://dora.dev/capabilities/monitoring-and-observability/) catch problems quickly, which also shortens [recovery time](/docs/engineering-delivery/failed-deployment-recovery-time).
7. **Do not add more approvals.** It is tempting to respond to failures with another sign-off step. DORA found that heavyweight external approvals did not lower change fail rates and made delivery slower ([streamlining change approval](https://dora.dev/capabilities/streamlining-change-approval/)).

> **Note:** If your team is adopting AI coding tools, keep an eye on this metric. DORA's 2025 report found AI adoption is still linked to higher delivery instability, and DORA's AI Capabilities Model names AI generating large, unstable changes as a risk that working in small batches counters. See [AI and software delivery](/docs/engineering-delivery/ai).

## Common mistakes

- **Counting caught bugs as failures.** A problem stopped before production is a success of your pipeline, not a failure.
- **Hiding failures to protect the number.** If people stop labelling hotfixes because the rate is watched, the number becomes useless. Never use it to judge people.
- **Reading only the team total.** It hides the risky service. Look per service.
- **Chasing zero.** A team with a 0% fail rate may simply be deploying so rarely, or so cautiously, that it is slow. Read it next to [deployment frequency](/docs/engineering-delivery/deployment-frequency) and [change lead time](/docs/engineering-delivery/change-lead-time).

## How Solidafy measures it

In the Engineering Delivery app:

- Change fail rate is the deploys that were rolled back or hotfixed, over all deploys in the period you choose.
- **Change fail rate by service** shows "Which services' deploys need a fix", highest first, with how many deploys each rate rests on. It is read at service level and never used to compare teams.
- Each service is read against its own past, with no outside grade.
- The default goal comes from your own baseline: 10% better than your current value, once the app has measured it. DORA's 2025 report publishes no target, so no published figure is used. You can accept the default, edit it, or set your own goal. A default is a suggestion, never a grade, and it never raises an alert on its own.
- An alert can tell you when one service needs fixes clearly more often than every other.
- Nothing is estimated, and no one is named.

You find change fail rate on the Overview and, per service, on the **Quality** page; the [Quality guide](/docs/engineering-delivery/quality) explains what to do when one service needs fixes often.

## Learn more

From DORA:

- [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics/)
- [Accelerate State of DevOps Report 2024](https://dora.dev/research/2024/dora-report/)
- [State of AI-assisted Software Development 2025](https://dora.dev/research/2025/dora-report/)
- Capabilities: [test automation](https://dora.dev/capabilities/test-automation/), [monitoring and observability](https://dora.dev/capabilities/monitoring-and-observability/), [streamlining change approval](https://dora.dev/capabilities/streamlining-change-approval/)

Related Solidafy guides:

- [The five DORA metrics](/docs/engineering-delivery/dora-metrics)
- [Deployment rework rate](/docs/engineering-delivery/deployment-rework-rate)
- [Failed deployment recovery time](/docs/engineering-delivery/failed-deployment-recovery-time)
- [Quality signals](/docs/engineering-delivery/quality)
- [Code review speed and size](/docs/engineering-delivery/review)