Rework rate, the DORA metric that finally prices bad code
DORA rework rate as the fifth metric forces an uncomfortable question. If your software delivery looks faster on paper while your rework quietly explodes, are your équipes really high performing or just running in circles. This is where metrics stop being a dashboard accessory and start becoming a balance sheet signal.
Rework rate in the DORA framework measures the share of engineering activity spent on reactive work. That includes bug fixes after deployment, rollbacks, rewrites of recent changes, and deployment rework triggered by failed deployment incidents. Elite benchmarks show that benchmarks elite équipes keep this rework rate under roughly fifteen percent, while lagging teams often burn forty percent or more of their time on deployment recovery and production firefighting.
The original four DORA metrics — deployment frequency, lead time for changes, change failure rate, and recovery time — describe how quickly and safely software changes move to production. The DORA rework rate fifth metric adds a missing dimension by asking how much of that software delivery effort actually creates new value versus undoing yesterday’s mistakes. When you combine these key metrics, you finally see whether your delivery performance is compounding value or just resetting the same incident clock every sprint.
What rework rate measures, and what it does not
Rework rate is a ratio, not a feeling. You take the engineering time spent on reactive work in a period and divide it by the total engineering time, then you track that rate over several months to see whether your software delivery system is stabilising or decaying. The DORA metric is simple, but the discipline behind the data is not.
Reactive work includes bug fixes tied to recent deployments, urgent hotfixes, rollbacks, and deployment rework after a change fail or failed deployment. It also includes production support tasks that exist only because a previous change failure slipped through, such as manual data corrections or repeated deployment recovery steps. What it does not include is planned refactoring, deliberate architecture changes, or strategic platform engineering investments that reduce future failure rate and improve long term performance.
That boundary matters because some leaders try to game metrics DORA style by reclassifying rework as “technical debt initiatives”. When you blur that line, your dora metrics stop reflecting reality and your benchmarks elite comparisons become meaningless. A credible rework rate practice requires that each équipe tags work items consistently, so that the data linking incidents, deployments, and changes is auditable and trusted by finance.
How AI coding tools changed the DORA conversation
AI assisted coding has made it trivial to increase deployment frequency without touching the underlying system quality. GitHub Copilot, Amazon CodeWhisperer, and similar tools can cut lead time for small changes, which looks great on a metrics dashboard until your rework rate quietly doubles. The DORA rework rate fifth metric is the first one that exposes this trade off in a way a CFO can read in one slide.
DORA research shows that AI augmented équipes often report both higher throughput and a spike in reactive work, especially when review discipline is weak and change failure checks are superficial. In other words, the time changes from idea to production shrinks, but the share of that time spent on deployment recovery and bug chasing grows, which erodes the net ROI of the AI investment. When you track rework rate alongside fail rate and recovery time, you can separate genuinely high performing teams from those just generating more failed deployment noise.
Vendors like to promise thirty percent productivity gains without mentioning the extra rework their tools generate. Once you put rework rate on the same page as other dora metrics, those claims become falsifiable using your own engineering data instead of glossy benchmarks elite reports. The conversation shifts from “more lines of code per day” to “less unplanned work per quarter”, which is where serious software delivery leaders want it.
Instrumenting rework rate with real engineering data
To make the DORA rework rate fifth metric credible, you need instrumentation that respects how your équipes actually work. Start by defining a small taxonomy of work item types in your issue tracker that clearly distinguishes new feature delivery, planned refactoring, and reactive rework. Then wire those types into your deployment and incident tooling so that every change and every failed deployment can be traced back to a ticket.
Platforms like GitHub Insights, Jellyfish, LinearB, and Athenian already correlate pull requests, deployments, and incidents to compute dora metrics such as lead time and change failure rate. Extending them to track rework rate means tagging which pull requests and changes are reactive responses to production issues or deployment rework, and then aggregating the time spent by each team on those items. The more consistently your engineering managers enforce this tagging, the more reliable your metrics DORA view becomes for executive decision making.
For organisations investing in platform engineering, this instrumentation should be part of the platform’s product surface, not an afterthought. When you design an internal developer platform, as discussed in the analysis of what platform engineering actually costs and delivers, you want deployment pipelines, incident tooling, and change management to emit structured données about rework, deployment frequency, and deployment recovery. That way, you can compare delivery performance across teams and environments without arguing about whose spreadsheet is correct.
A practical tagging model that teams will actually use
Most tagging schemes fail because they are too clever. Engineers will not fill ten fields per ticket just to satisfy a metrics dashboard, so you need a minimal model that still captures the essence of rework rate and other key metrics. Three tags are usually enough for a first pass.
First, classify each work item as “value creating”, “preventive”, or “reactive”, where reactive maps directly to rework. Second, link reactive items to the deployment, change, or incident that triggered them, so you can compute change failure and failed deployment chains instead of isolated events. Third, ensure that your deployment tooling automatically stamps each production change with the related ticket, so that dora metrics like lead time and recovery time can be computed without manual reconciliation.
Once this model is in place, you can calculate the DORA rework rate fifth metric per équipe, per service, and per product line. Over time, you will see which teams are genuinely high performing and which ones are hiding a high rework rate behind impressive deployment frequency. That visibility is what allows product leaders to rebalance time between new features and hardening the production system.
Why Git and incident data must tell the same story
Rework rate is only as trustworthy as the data behind it. If your Git history, incident tickets, and deployment logs disagree about what happened, your metrics DORA view becomes a political artefact instead of an operational tool. The goal is for every change in production to have a single source of truth across systems.
Start by enforcing that every pull request references a work item, and every production deployment references the merged pull requests it contains. Then ensure that every incident or change fail record links back to the deployment that introduced the problem, so that deployment recovery and deployment rework can be measured precisely rather than guessed. When these links are in place, you can compute rework rate, failure rate, and recovery time with confidence, and you can slice the data by team, service, or environment without manual heroics.
This alignment also protects you against gaming. If an équipe tries to reclassify reactive work as planned change, the mismatch between incident logs and Git history will show up in your dora metrics dashboards. Over time, leaders learn to trust the DORA rework rate fifth metric because it is grounded in consistent engineering data rather than self reported status updates.
Reading rework rate alongside the original four DORA metrics
Looking at rework rate in isolation is like reading only one line of a profit and loss statement. The power of the DORA rework rate fifth metric emerges when you read it alongside deployment frequency, lead time, change failure rate, and recovery time. Together, these five metrics describe not just how fast your software delivery engine runs, but how much of that motion actually moves the business forward.
Consider a team with high deployment frequency, short lead time, and a low reported failure rate, but a rework rate above forty percent. On paper, this looks like a high performing équipe, yet half of its engineering time is spent on deployment rework, bug fixes, and production clean up, which means the roadmap is slipping even as the dashboards glow green. In contrast, a team with moderate deployment frequency, slightly longer lead time, and a rework rate under fifteen percent is quietly compounding value, because most of its changes stick the first time.
These patterns matter when you compare squads, tribes, or product lines. A CFO or COO cares less about raw dora metrics than about how those metrics translate into cost of delay, customer churn, and margin erosion from repeated change failure. Rework rate is the bridge between engineering performance and financial performance, because it quantifies how much of your payroll is spent on undoing previous work instead of shipping new capabilities.
Four diagnostic patterns every delivery leader should recognise
Once you track the DORA rework rate fifth metric for a few quarters, recurring patterns emerge. The first pattern is “fast but fragile”, where deployment frequency and lead time look excellent, yet rework rate and fail rate are high, signalling that teams are optimising for speed at the expense of stability. The second pattern is “slow and safe”, where change failure is low and recovery time is acceptable, but deployments are rare and rework still consumes a surprising share of time.
The third pattern is “stuck in firefighting”, where rework rate dominates the engineering calendar, deployment recovery is constant, and new feature delivery barely moves, even if individual changes are small. The fourth pattern is “quietly elite”, where rework rate stays under fifteen percent, deployment frequency is steady, and the failure rate is low enough that production incidents are rare and boring. In this last case, the dora metrics tell a story of disciplined engineering, strong testing, and a culture that treats change fail events as learning opportunities rather than blame sessions.
These patterns give you a vocabulary for executive reviews. Instead of arguing about whether a team is “good” or “bad”, you can say “this équipe is fast but fragile, and our priority is to reduce rework rate without sacrificing delivery performance”. That framing invites targeted investment in testing, observability, and platform capabilities rather than generic calls for “more productivity”.
How architecture choices show up in rework rate
Architecture decisions leave fingerprints on your DORA metrics. A tightly coupled monolith with shared databases often shows low deployment frequency and high rework rate, because every change risks unexpected side effects and deployment rework across modules. A well designed microservices system can improve deployment frequency and reduce recovery time, but only if the operational model is mature.
Leaders wrestling with the microservices versus monolith debate should pay attention to how rework rate behaves during migrations. When teams split a monolith into services without investing in observability, testing, and deployment recovery automation, the failure rate and change failure metrics often spike, and rework consumes more of the roadmap than before. The detailed decision framework in the analysis of microservices versus monolith for grown ups is most useful when paired with your own DORA rework rate fifth metric trends.
Over time, you want architecture choices that reduce the share of reactive work, not just the average lead time for individual changes. That means designing systems where a failed deployment is cheap to roll back, where deployment rework is rare, and where teams can ship changes independently without triggering cascading incidents. Rework rate becomes the feedback loop that tells you whether your architecture strategy is paying off in real production conditions.
The CFO conversation: roadmap quality versus roadmap velocity
Finance leaders have grown sceptical of engineering dashboards that show only throughput. They care about how much of the engineering budget turns into durable software assets versus how much is lost to rework, deployment recovery, and repeated change failure. The DORA rework rate fifth metric gives them a clean, auditable ratio they can track over time.
When you walk a CFO through dora metrics, start with the original four to explain how quickly and safely changes move into production. Then introduce rework rate as the percentage of engineering time spent on reactive work, and show how that rate correlates with customer incidents, support tickets, and revenue at risk. A rework rate above forty percent means nearly half of your payroll is spent undoing previous work, which is a direct hit to margin and a clear signal that roadmap quality is suffering.
This framing changes investment debates. Instead of arguing about whether to hire more engineers to increase deployment frequency, you can ask whether reducing rework rate by ten points would free enough capacity to meet roadmap commitments with the current équipes. For a CFO, that is a concrete, ROI focused conversation grounded in metrics DORA can support rather than a vague promise of “more productivity”.
Turning rework rate into a financial KPI
To make rework rate meaningful for finance, translate it into cost and risk. Start by estimating the fully loaded monthly cost of your engineering teams, then multiply that by the rework rate to quantify how much you spend on reactive work each month. This gives you a baseline for the financial impact of deployment rework, failed deployment incidents, and chronic change fail patterns.
Next, connect rework driven incidents to customer outcomes. For example, if a high failure rate in a payments service caused three hours of downtime, you can estimate the revenue at risk and the support cost generated by those production issues. When you show that a five point reduction in rework rate could have avoided a specific set of incidents, the DORA rework rate fifth metric stops being an abstract engineering number and becomes a lever in budget planning.
Finally, track how investments in testing, observability, or platform engineering affect rework rate over several quarters. If a new test automation suite reduces change failure and recovery time while also lowering rework rate, you can attribute part of the cost savings to that initiative. This is how rework rate evolves from a technical curiosity into a board level KPI that shapes strategy.
Why AI productivity claims must pass the rework test
AI vendors often pitch a simple story to finance leaders. They promise that AI assisted coding will reduce lead time, increase deployment frequency, and improve delivery performance by double digit percentages. Without rework rate on the dashboard, those claims are hard to challenge.
Once you adopt the DORA rework rate fifth metric, the evaluation changes. You can run a controlled rollout of an AI coding tool, measure how dora metrics such as lead time, failure rate, and recovery time shift, and then compare that to the change in rework rate over the same period. If deployment frequency rises but rework rate and fail rate also climb, the net effect on software delivery may be negative, even if individual engineers feel faster.
This is why serious CFOs now ask for before and after DORA metric baselines when approving AI tooling budgets. They want to see whether AI reduces the share of reactive work or simply accelerates the production of changes that later require deployment rework. In that sense, rework rate becomes the falsification test for any “thirty percent productivity gain” story.
A monthly executive report layout that surfaces rework
Most executive reports on software delivery are either too technical or too shallow. A good monthly pack uses the DORA rework rate fifth metric to connect engineering reality with business outcomes in a way non engineers can follow. The structure matters as much as the numbers.
Start with a single page that shows the five core dora metrics over the last six months: deployment frequency, lead time for changes, change failure rate, recovery time, and rework rate. For each metric, highlight whether the trend is improving, stable, or degrading, and annotate major events such as a platform migration, a new release train, or a spike in failed deployment incidents. This gives executives a time series view of delivery performance without drowning them in raw data.
The second page should translate these metrics into capacity and risk. Show how much engineering time was spent on rework versus new feature delivery, how many production incidents were tied to change fail events, and how deployment recovery times affected customer facing SLAs. When leaders see that a high rework rate is consuming a third of the roadmap capacity, the case for investing in quality becomes self evident.
Segmenting by team and product without starting a blame game
Executives need to see variation across équipes and products, but they do not need a public leaderboard. The goal is to identify where support is needed, not to shame teams with higher rework rate or failure rate. A simple segmentation approach works best.
Group teams into clusters by product line or domain, and show average dora metrics and rework rate for each cluster rather than for individual squads. Highlight where deployment frequency is constrained by shared infrastructure, where recovery time is long because of manual deployment recovery steps, and where deployment rework is concentrated in a few brittle services. This keeps the focus on systemic constraints rather than personal performance.
Over time, you can use these segmented metrics DORA views to guide coaching, platform investments, and architecture changes. High performing clusters with low rework rate can mentor others, while clusters with chronic change failure can receive targeted support in testing and observability. The monthly report becomes a learning tool rather than a compliance artefact.
Linking DORA numbers to external benchmarks
Internal trends matter, but leaders also want to know how they compare to peers. This is where external DORA research and vendor analyses become useful, as long as you treat them as directional rather than prescriptive. The key is to align definitions before you align numbers.
When you read public benchmarks elite reports on dora metrics, check whether their definition of rework rate matches yours, and whether they include the same types of reactive work. Then compare your deployment frequency, lead time, failure rate, and recovery time bands to those published ranges, using your own DORA rework rate fifth metric as the lens for interpreting gaps. If you are slower than peers but have a much lower rework rate, your priority may be to safely increase deployment frequency, whereas if you are faster but have higher rework, your priority is to reduce change fail incidents.
For a deeper dive into how AI is shifting these benchmarks, the analysis on benchmarking delivery and the DORA numbers AI is actually moving provides useful context. Pair those external insights with your own metrics DORA trends, and you will have a grounded view of where your software delivery stands. The goal is not to chase vanity rankings, but to ensure your engineering investments produce compounding value rather than compounding rework.
Using rework rate to steer product and platform strategy
Product and delivery leaders sit at the intersection of roadmap ambition and engineering reality. The DORA rework rate fifth metric gives them a way to argue for quality without sounding like they are slowing the business down. It turns vague concerns about “tech debt” into measurable drag on delivery performance.
When you plan a quarter, allocate capacity explicitly between new features, preventive work, and rework, and then track how the actuals compare to the plan. If rework rate consistently overshoots the plan, you have evidence that either your quality gates are too weak or your architecture is amplifying change failure. In both cases, the right response is not to push teams for more deployments, but to invest in the practices and platforms that reduce deployment rework and failed deployment incidents.
Over several quarters, you can use rework rate trends to justify platform engineering initiatives, refactoring efforts, or changes in release strategy. A sustained drop in rework rate after a major platform upgrade is a strong signal that the investment is paying off, even if deployment frequency or lead time did not change dramatically. For senior leaders, this is the kind of evidence that makes it easier to defend long term bets in steering committees.
From vanity velocity to durable value
Velocity metrics are easy to game. Teams can increase story points, slice work thinner, or ship more deployments without improving customer outcomes or reducing failure rate. The DORA rework rate fifth metric resists this kind of inflation because it focuses on the share of time lost to reactive work.
When you combine rework rate with dora metrics such as deployment frequency and recovery time, you get a more honest picture of whether your software delivery system is creating durable value. A team that ships fewer but more reliable changes, with low change failure and minimal deployment rework, will often outperform a team that ships more but spends half its time cleaning up. Over time, this distinction shows up not just in dashboards, but in customer satisfaction, churn, and the stability of your production environment.
For leaders in the future of software, the message is simple. Measure what hurts, not just what moves, and treat rework rate as the price you pay for velocity in the wrong direction. The systems that win are the ones that keep that price low when it matters most — not the keynote demo, but the third quarter in production.
Key figures on DORA rework rate and delivery performance
- DORA research reports that elite teams typically keep rework rate under roughly 15 percent of total engineering effort, while underperforming teams often exceed 40 percent, which means almost half their capacity is spent on reactive work rather than new value.
- Organisations that achieve both high deployment frequency and low change failure rate are more than twice as likely to meet their commercial goals compared with those that deploy less frequently and suffer higher failure rates, highlighting the compound effect of strong delivery performance.
- Mean Time to Recovery, reframed as failed deployment recovery time in the updated DORA framework, is a critical driver of customer experience because even a reduction from hours to minutes can cut the business impact of incidents by an order of magnitude.
- Studies of AI assisted teams show that while coding throughput can increase by 20 to 30 percent, rework and reactive bug fixing can also spike significantly when review discipline is weak, which means the net productivity gain depends heavily on governance.
- Industry surveys consistently find that teams with mature DORA metric practices, including explicit tracking of rework rate, are significantly more likely to report both higher employee satisfaction and better financial outcomes than teams without such measurement.
FAQ about the DORA rework rate fifth metric
How is DORA rework rate actually calculated in practice?
DORA rework rate is calculated by dividing the engineering time spent on reactive work, such as bug fixes, rollbacks, and deployment rework, by the total engineering time in a given period. Teams usually approximate this by tagging work items in their issue tracker as reactive and summing the effort logged against them. The resulting percentage shows how much of the delivery capacity is consumed by undoing or correcting previous changes.
What is a good DORA rework rate target for high performing teams?
Elite teams typically aim to keep rework rate below about 15 percent of total engineering effort over a sustained period. A rate between 15 and 25 percent is common for healthy but still maturing organisations, while anything consistently above 30 to 40 percent signals serious quality or architecture problems. The exact target should reflect your domain risk, but the trend over time is usually more important than a single threshold.
How does rework rate relate to the original four DORA metrics?
Rework rate complements the original four DORA metrics by measuring how much of your delivery effort is spent reacting to problems rather than shipping new value. Deployment frequency and lead time show how fast you move, while change failure rate and recovery time show how safely you move. Rework rate then reveals how much of that motion is wasted on fixing issues created by previous deployments.
Can rework rate be improved without slowing down deployment frequency?
Yes, many teams reduce rework rate while maintaining or even increasing deployment frequency by investing in better testing, observability, and release practices. Techniques such as feature flags, canary releases, and automated rollback reduce the impact of change failure and make deployment recovery faster and less disruptive. Over time, these practices allow teams to ship small, low risk changes frequently with minimal rework.
Why do finance and executive leaders care about rework rate?
Finance leaders care about rework rate because it quantifies how much of the engineering budget is spent on reactive work instead of new capabilities. A high rework rate means a large share of payroll is effectively paying for past mistakes, which erodes margin and delays roadmap commitments. By tracking rework rate alongside other DORA metrics, executives can make more informed decisions about where to invest in quality, platform engineering, or process improvements.