Deployment Rework Rate: The Fifth DORA Metric Most Teams Can't Measure

Change failure rate tells you how often a deploy goes wrong. Rework rate tells you how much of your delivery capacity goes into cleaning up afterwards.

---

For most of the last decade, "DORA metrics" meant four numbers: deployment frequency, lead time for changes, change failure rate, and time to restore service. In 2024, Google's DevOps Research and Assessment team quietly added a fifth: deployment rework rate. It's the newest of the five metrics, the least tracked, and arguably the one that says the most about what your engineers actually spend their week doing.

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." In plain terms: of all the times you shipped to production, how many were emergency fixes for something that broke, rather than planned work?

Rework rate = unplanned deployments caused by production incidents
              ÷ total production deployments

A Worked Example

Say your team made 120 production deployments last month. Looking back at them:

• 102 were planned releases - features, scheduled upgrades, routine config changes
• 18 were unplanned: hotfixes, fix-forwards, and emergency patches shipped because an incident was open

Your deployment rework rate is 18 ÷ 120 = 15%. Roughly one deploy in seven was the team paying back a problem, not delivering something new.

Rework Rate vs. Change Failure Rate: What's the Difference?

The two metrics sound similar, and DORA groups them together, but they count different things.

	Change failure rate	Deployment rework rate
Counts	Deployments that caused a failure needing immediate intervention	Deployments that were made because of a production incident
Question it answers	How often do our changes break production?	How much of our shipping is cleanup?
Typical numerator	The bad release	The hotfixes that followed it

One bad release can produce one failed deployment and three rework deployments - the first hotfix that didn't quite work, the second that did, and the follow-up that cleaned up the data. Change failure rate counts that incident once. Rework rate shows you the full cost of it in delivery capacity.

Why DORA Added a Fifth Metric

DORA's own explanation is that change failure rate had been acting as a proxy for rework. As their metrics history puts it, researchers "identified that change failure rate - the percentage of deployments requiring hotfixes or rollbacks - acted as a proxy for the amount of rework a team must perform. To test this, they introduced a fifth metric: deployment rework rate."

At the same time, DORA reorganised the metrics into two factors:

• Throughput: change lead time, deployment frequency, failed deployment recovery time
• Instability: change fail rate, deployment rework rate

The shift in wording from "stability" to "instability" is deliberate. Both instability metrics measure the same underlying pain from two angles: how often you break things, and how much work it takes to un-break them. (The same reworking renamed the old MTTR to failed deployment recovery time in 2023, so it only counts failures caused by your own changes - not data centre outages.)

Why Rework Rate Matters More in 2026

Teams are shipping more code, faster, than ever - much of it now drafted by AI assistants. Deployment frequency going up looks like progress on a dashboard. Rework rate is the check on whether it actually is. If your deploy count doubles but a third of the new deploys are hotfixes, you haven't doubled delivery; you've doubled churn.

That's why rework rate is the metric engineering leaders should watch alongside any productivity initiative. It's also a direct line to the problem this blog keeps returning to: 80% of production outages are self-inflicted, and every one of them generates rework.

Why Most Teams Can't Measure It

Rework rate looks easy - it's one division. In practice almost nobody has the numerator, because it needs two things most deployment histories don't record:

1. Intent. Was this deploy planned or reactive? CI/CD logs say a pipeline ran; they don't say why. A hotfix and a feature release look identical in a pipeline history.
2. A link to the incident. To count a deploy as rework, you have to know it was shipped because of a production problem. That connection lives in someone's memory, a Slack thread, or a postmortem written a week later.

So teams estimate. And an estimated instability metric is one nobody acts on.

How to Measure Deployment Rework Rate

The fix is to capture intent at the moment of the change, when it costs nothing, instead of reconstructing it later.

With OpsTrails deployment tracking, every change your pipelines make is recorded as a structured event. Recording a reactive deploy differently is a one-word change - use a hotfix event type (or keep deployment and add context in data), and reference the incident it fixes:

{
  "specversion": "1.0",
  "type": "hotfix",
  "source": "//github.com/acme/checkout-service",
  "time": "NOW",
  "subject": "production",
  "severity": "CRITICAL",
  "version": "4.12.1",
  "data": {
    "description": "Fix null customer ID in payment retry path",
    "incident": "INC-2291"
  }
}

From there, rework rate is a query, not a quarterly spreadsheet exercise. Your AI assistant can answer it directly over MCP: "How many production deploys last month were hotfixes, and which services did they touch?" - and the follow-up that matters more: "Which planned release caused the most hotfixes?"

That last question is where rework rate becomes actionable. A high rework rate concentrated in one service points at test coverage or review practice there. Rework that clusters after Friday releases points at a process. Rework that follows config changes points at configuration drift. You can't see any of those patterns until intent and incident are on the same timeline as the deploy itself.

The Takeaway

Change failure rate tells you how often you break production. Deployment rework rate tells you what that costs - in deploys, in engineering hours, in features that didn't ship. Track both, and record the why of every deploy at the moment it happens. It's the only point in time when that information is free.

---

OpsTrails records every deployment, hotfix, and rollback on one timeline - with the intent and the incident attached. Rework rate stops being a guess.

→ Start tracking free

---

Sources: DORA metrics guide and metrics history (dora.dev), Google DORA Accelerate State of DevOps Report (2023, 2024), DORA State of AI-assisted Software Development (2025).