# Deployment rework 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.

Deployment rework rate is the share of your deployments that you did not plan, but had to make because something was broken in production. It is the newest of the five DORA metrics, added in 2024, and it shows how much of your delivery capacity goes into putting things right rather than moving forward.

## What is deployment rework rate?

DORA defines it as:

> "The ratio of deployments that are unplanned but happen as a result of an incident in production."

Some terms in plain words:

- A [deployment](/docs/engineering-delivery/glossary#deployment) is putting a change live in [production](/docs/engineering-delivery/glossary#production), the system your users actually use.
- An [incident](/docs/engineering-delivery/glossary#incident) is a problem in production that affects users: an error, an outage, a broken feature.
- An **unplanned** deployment is one you made because of that problem, not because it was on your roadmap.

[Rework](/docs/engineering-delivery/glossary#rework) is any work spent redoing or repairing something that was supposedly finished. Deployment rework rate counts the deployments that are rework.

Our example team of six, building an online booking app, made 50 deployments last quarter. Six of them were not planned: they were made while an incident was open, to stop double bookings, restore a broken login and fix a pricing error. Their deployment rework rate is 6 out of 50, which is 12%.

Deployment rework rate is one of DORA's two **instability** metrics, together with [change fail rate](/docs/engineering-delivery/change-fail-rate).

## Why did DORA add it?

For years DORA used four metrics, often called the four keys. Change fail rate was always a bit of an odd one out. DORA explains that it "is strongly correlated with the other three metrics but statistical tests and methods prevent us from combining all four into one factor" (2024 report, p.11).

DORA had a long-standing hypothesis that "the change failure rate metric works as a proxy for the amount of rework a team is asked to do". When a delivery fails, the team has to fix the change, "likely by introducing another change" (2024 report, p.11).

To test this, the 2024 survey added a new question:

> "For the primary application or service you work on, approximately how many deployments in the last six months were not planned but were performed to address a user-facing bug in the application?" (2024 report, p.11)

The analysis confirmed the idea: rework rate and change fail rate are related, and "together, these two metrics create a reliable factor of software delivery stability" (2024 report, p.11). That is how DORA went from four metrics to five.

## How is it different from change fail rate?

The two are close cousins, but they ask different questions.

| | Change fail rate | Deployment rework rate |
| --- | --- | --- |
| The question | How often does a deployment break something? | How much of our deploying is spent fixing things? |
| What it counts | Deployments that needed immediate intervention, such as a rollback or hotfix | Deployments that were unplanned and caused by a production incident |
| What it reveals | How risky each change is | How much capacity goes into repair |

A simple way to see the difference: a single bad deployment counts once in change fail rate. If it then takes three more emergency deployments to fully fix the problem, all three count as rework. A team can have a modest change fail rate and still spend a lot of its deploying on repairs, if each failure takes several attempts to put right.

## Why does it matter?

- **It is time taken from planned work.** Every unplanned deployment is time and attention the team meant to spend on something else.
- **It shows hidden cost.** A team can look fast on [deployment frequency](/docs/engineering-delivery/deployment-frequency) while a large share of those deployments are firefighting.
- **It points at quality debt.** A rising rework rate often means problems are reaching production that earlier checks should have caught.

DORA's 2026 report on the return on AI investment makes the same point in money terms: teams with the best delivery performance get their returns "by reducing the amount of unnecessary rework", which "recovers engineering capacity equivalent to 'free headcount'" (DORA, The ROI of AI-assisted Software Development, p.5).

## How do you measure it?

Count the deployments that were unplanned and made because of a production incident. Divide by all deployments to production in the same period.

The tricky part is deciding which deployments were unplanned and caused by an incident. Two practical approaches:

- **Use your incident tool.** If incidents are recorded with an opened and resolved time, a deployment made while an incident was open, to the affected [service](/docs/engineering-delivery/glossary#service), is very likely rework.
- **Label changes.** Ask people to mark emergency fixes with a label or link them to the incident they address.

Some edge cases:

- **Only resolved incidents should link deployments.** An incident left open for weeks by mistake would otherwise mark every deployment after it as rework.
- **Name the service on the incident.** If an incident does not say which service it affected, you can only link it to the whole team's deployments, which is less precise.
- **No incident data means no number.** Without some record of incidents, you cannot tell planned from unplanned deployments. It is better to show nothing than to guess.

## What does good look like?

The 2024 DORA report did not publish performance level figures for rework rate. Its cluster analysis used the original four metrics "to remain consistent with previous years' cluster analyses" (2024 report, p.13).

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

| Share of deployments that were unplanned fixes | Share of respondents |
| --- | --- |
| 0% to 2% | 6.9% |
| 2% to 4% | 5.8% |
| 4% to 8% | 13.7% |
| 8% to 16% | 26.1% |
| 16% to 32% | 24.7% |
| 32% to 64% | 15.4% |
| More than 64% | 7.3% |

The most common answers were 8% to 16% and 16% to 32%. About half of respondents (52.6%) reported 16% or less.

As with every DORA metric, the most useful comparison is with your own past. A falling rework rate means more of your deploying goes into moving forward. See [DORA performance levels](/docs/engineering-delivery/performance-levels#the-2024-performance-levels) for more on using benchmarks.

## How do you improve it?

Rework rate goes down when fewer problems reach production, and when the ones that do are fixed in one go.

1. **Look for patterns.** Open the deployments made under recent incidents and look at which services they share. Rework often clusters in one fragile area.
2. **Find the cause, not just the symptom.** After each incident, ask why the problem reached users and what check would have caught it. Add that check. [Test automation](https://dora.dev/capabilities/test-automation/) and [continuous integration](https://dora.dev/capabilities/continuous-integration/) help.
3. **Ship smaller changes.** Small changes are easier to test, review and fix correctly the first time. See DORA's [working in small batches](https://dora.dev/capabilities/working-in-small-batches/) and [Change size](/docs/engineering-delivery/review#change-size).
4. **Prefer a clean rollback over rushed fixes.** Rolling back to a known good version, then fixing calmly, often needs fewer emergency deployments than several hurried fixes forward.
5. **Catch problems early.** [Monitoring and observability](https://dora.dev/capabilities/monitoring-and-observability/) shorten the time a problem exists, and so the pressure to rush a fix.
6. **Read the quality signals alongside it.** Bugs opened and reopened tickets show the same problems from the tracker's side. See [Quality signals](/docs/engineering-delivery/quality).

## Common mistakes

- **Counting all hotfixes the same way.** A planned small follow-up is not rework. Rework is unplanned and caused by a production problem.
- **Guessing without incident data.** Without a record of incidents, you cannot separate rework from normal deployments. Do not estimate.
- **Leaving incidents open.** An incident nobody closes can make every later deployment look like rework.
- **Reading it alone.** A low rework rate is less meaningful if you hardly deploy. Read it with [deployment frequency](/docs/engineering-delivery/deployment-frequency) and [change fail rate](/docs/engineering-delivery/change-fail-rate).

## How Solidafy measures it

In the Engineering Delivery app:

- Rework rate reads incidents from the incident source you choose in Settings.
- A deploy counts as unplanned when it shipped while an incident was open: to the service the incident names, or, when it names none, to a service of the incident's team.
- Only a resolved incident links deploys, so one left open never marks every deploy after it.
- The rate is those deploys over all deploys in the period you choose.
- Without an incident source, rework rate is not measured, and never estimated.
- Because DORA publishes no level figure for rework rate, its default goal comes from your own baseline rather than a benchmark, and it is read against your own past.

You find the rework rate tile on the **Quality** page, and the **Incidents** page explains how it is measured under "How these are measured"; the [Quality guide](/docs/engineering-delivery/quality) and the [Incidents guide](/docs/engineering-delivery/incidents) explain what to do when it rises.

## 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/), [working in small batches](https://dora.dev/capabilities/working-in-small-batches/), [monitoring and observability](https://dora.dev/capabilities/monitoring-and-observability/)

Related Solidafy guides:

- [The five DORA metrics](/docs/engineering-delivery/dora-metrics)
- [Change fail rate](/docs/engineering-delivery/change-fail-rate)
- [Failed deployment recovery time](/docs/engineering-delivery/failed-deployment-recovery-time)
- [Quality signals](/docs/engineering-delivery/quality)