A team checks its change failure rate and feels good: comfortably in the Elite band. Failures are rare. And yet the week does not feel rare. There is a deploy to patch the thing that broke, then a deploy to fix the patch, then a config change to settle it down. The dashboard says stability is excellent. The team spends half its release capacity cleaning up after itself. The number that would explain the contradiction is the one the team is not looking at.
Deployment rework rate is the fifth DORA metric, added in the 2024 DORA Report, and it catches exactly what change failure rate misses: not whether a deploy failed, but how much reactive, unplanned deployment work your failures generate. A low change failure rate can still hide a team that recovers from every incident with a string of catch-up deploys.
It is one of the five DORA metrics and the third of the three stability metrics, alongside change fail rate and failed deployment recovery time. What follows is why DORA added a fifth metric at all, what rework rate measures that the other four do not, why it has no performance bands yet, and how to bring it down.
What deployment rework rate measures
Deployment rework rate is the proportion of deployments that are unplanned and happen as a result of a production incident, rather than as planned feature work. Where change failure rate counts the deploys that need immediate intervention, rework rate counts the unplanned deploys those problems generate, whether the incident lands minutes after the release or surfaces weeks later: the hotfix, the fix to the hotfix, the config change to settle it. Read as a ratio, it tells you how much of your deployment activity is reactive cleanup rather than forward progress.
The distinction from change failure rate is the whole point. A team with a low change failure rate but a high rework rate is failing rarely and remediating often. Two teams can report the same change failure rate while one recovers with a single clean fix and the other thrashes through five. Rework rate is the metric that separates them.
Why DORA added a fifth metric
For most of its history the DORA framework had four metrics: two for throughput (deployment frequency and change lead time) and two for stability (change fail rate and failed deployment recovery time). The 2024 DORA Report added deployment rework rate as a third stability signal because the original two left a blind spot. Change failure rate tells you how often you break production. Recovery time tells you how long each break lasts. Neither tells you how much follow-up deployment work the break creates.
That blind spot matters because reactive deploys are a cost the other metrics never bill. A failure that is fixed in twenty minutes looks healthy on recovery time, but if the fix took four follow-up deploys to land, the team paid for four deploys worth of review, CI, and risk that no feature work benefited from. Rework rate makes that hidden cost visible. Together the three stability metrics answer how often you break, how long it lasts, and how much it costs you in unplanned releases.
No performance bands yet: track the trend
One honest caveat sets rework rate apart from the other four. DORA has not yet published Elite / High / Medium / Low thresholds for it the way it has for deployment frequency, lead time, change fail rate, and recovery time. It is too new. That means there is no benchmark to score yourself against, and anyone presenting a rework-rate performance band is inventing one.
The right way to use it, until bands exist, is as a trend on your own team. Is the proportion of reactive deploys rising or falling quarter over quarter? A rising rework rate alongside a flat change failure rate is the clearest possible signal that recovery is getting messier even though failures are not getting more frequent. As with every DORA metric, this only works if rework stays defined consistently. The gaming vector here is reclassification: a follow-up deploy quietly relabelled as planned feature work, a hotfix recorded as a routine release. The number improves; the thrash it was meant to measure does not. Treat it as a team-level diagnostic, never an individual target.
How to derive it from pipeline data
Rework rate needs you to identify which deploys were reactive, which is a causal-attribution problem rather than a counting one. Three signals link a deployment to a prior incident, in descending order of clarity: a revert or rollback deploy that undoes a previous change; a fix-forward deploy inside a short window after a failed one (the same window you would use for change failure rate); and a deploy explicitly linked to a declared incident. The practical decisions behind attributing deploys to incidents are covered in how to measure DORA metrics.
The denominator is every deployment over the window, the same one change failure rate uses, which is why a consistent definition of "deployment" underpins both. A deployment is best treated as whatever a service's deployment rule says it is, not as every workflow run, so that planned and reactive deploys are counted on the same basis.
How to bring rework rate down
Because rework rate measures the thrash after a failure, you lower it by recovering cleanly rather than by recovering fast. The practices overlap with the other stability metrics, which is the point: the same investments improve all three at once.
- Root-cause fixes over patch-on-patch. The string of follow-up deploys usually comes from fixing symptoms under pressure. A single deploy that addresses the cause beats three that chase the effects.
- Rollback as the first response. Reverting to the last good deploy resolves the incident with one action and buys time to fix the cause properly, instead of fixing forward live and generating rework.
- Small batches. A small change that fails is easy to reason about and fix once. A large change that fails spawns follow-up deploys as each hidden interaction surfaces in turn.
- Feature flags. A problem caught behind a flag is a toggle, not a redeploy, so it never enters the rework count in the first place.
How CI/CD Watch surfaces deployment rework rate
CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, derives the stability metrics from the same per-service deployment rules, which is what lets rework rate share a consistent deployment definition with change failure rate. Attributing a deploy to a prior incident depends on revert, fix-forward, and incident signals, so rework rate is most accurate when those sources are connected. How each rule is evaluated is set out in the DORA metrics reference.
Stability-metric trends sit on the Team plan and above. The Free tier covers pipeline-run monitoring, which is enough to confirm the upstream signals (deploy outcomes, rerun volume, deployment cadence) are coherent before layering stability analysis on top. Because rework rate has no published DORA band, the product tracks it as a trend rather than scoring it against a threshold, in line with how the metric is meant to be read.
See your stability metrics across providers
CI/CD Watch's Free tier covers pipeline-run monitoring for small teams. Connect a provider to see deploy outcomes and cadence across your workflows, the upstream signals the rework-rate calculation depends on. Stability-metric trends live on the Team plan and above. For the broader framework this metric sits inside, the DORA metrics overview covers all five.
CI/CD Watch is built by 3CS Technologies Ltd. It started as an internal tool for tracking pipeline health across a mixed GitHub Actions and Jenkins estate. The same engine now powers the SaaS platform.