DORA Metrics Changed: Why Are There Five Metrics Now?
In 2024, DORA formally added deployment rework rate to its established set of software delivery performance metrics, expanding the model from four metrics to five. The new metric measures the share of deployments that were unplanned and made in response to a production incident, which makes reactive delivery work visible instead of leaving change fail rate to act as a proxy for that rework.
By separating those signals, the model becomes more specific: engineering leaders can distinguish deployments that require immediate intervention from the additional deployments teams make to correct production problems. That distinction matters when you evaluate delivery performance, compare current reporting with historical dashboards, or decide how to update your measurement practices.
DORA moved to five key metrics in 2024
The current DORA model contains five software delivery performance metrics across two dimensions: three describe throughput, while two describe instability.
| Current dimension | Metric | What it answers |
|---|---|---|
| Throughput | Change lead time | How long a change takes to move from commit to production |
| Throughput | Deployment frequency | How often an organization deploys changes to production |
| Throughput | Failed deployment recovery time | How long it takes to recover from a failed deployment |
| Instability | Change fail rate | The share of deployments that require immediate intervention |
| Instability | Deployment rework rate | The share of deployments that are unplanned responses to production incidents |
If you need a refresher on the historical four-metric model, see our earlier DORA metrics explainer. Even so, the important update is that deployment rework rate now appears as a separate instability metric rather than remaining implicit inside another measurement.
The current five DORA metrics
The five metrics should be read together because each describes a different part of the software delivery system. Deployment frequency and change lead time show the pace of delivery, and failed deployment recovery time shows how quickly the organization recovers when a deployment causes a failure. Change fail rate shows how often deployments require immediate intervention, and deployment rework rate shows how much deployment activity is reactive and unplanned because of production incidents.
Together, these signals help prevent a high deployment count from being interpreted as healthy by itself, since some deployments may represent planned product delivery while others may be corrective work that displaced the plan. The fifth metric gives teams a way to separate those two kinds of activity.
Reliability and recovery terminology changed first
The path from four to five was not a single naming update. In 2021, DORA discussed reliability as an additional dimension and sometimes referred to it as a fifth metric; however, DORA's own history later described that wording as imprecise because reliability did not behave like the four software delivery performance metrics.
Recovery terminology also changed, as DORA refined time to restore service into failed deployment recovery time in 2023 so the measurement would focus on impairments caused by software deployments. Deployment rework rate then became an actual fifth metric in 2024.
As a result, current sources can appear inconsistent even when each one accurately reflects the version available when it was published, because a source that says “four metrics plus reliability” is not describing the same structure as the current five-metric model.
Why DORA added deployment rework rate
DORA added deployment rework rate because change fail rate had been doing two jobs: it measured the proportion of deployments that required immediate intervention while also acting as a proxy for the rework created by failures. By introducing a separate metric, DORA could test and measure that rework more directly.
The distinction is operationally important because the metrics answer different questions. A failed change asks: did this deployment require an immediate response such as a rollback, hotfix, or other intervention? Rework asks: how much later deployment activity was unplanned because the team needed to address a production incident?
Let's consider a hypothetical period with 100 deployments: five require immediate intervention, producing a 5% change fail rate, while teams make eight unplanned deployments to address production incidents, producing an 8% deployment rework rate. These figures are illustrative rather than benchmarks, and they differ because the two metrics count different events: the deployment that failed and the corrective deployments that followed.
Since each ratio counts a different event, one failed deployment can, in principle, lead to more than one corrective deployment. Depending on the reporting window, a rework deployment can also be counted in a different period from the original failure. These are inferences from the metric definitions, not separate DORA classification rules, and they show why treating the ratios as interchangeable can hide an important difference.
How deployment rework rate is calculated
Deployment rework rate is the ratio of unplanned deployments made because of production incidents to all deployments in the same measurement period; expressed as a percentage, the calculation is:
Deployment rework rate = (unplanned deployments made to address production incidents / total deployments) × 100
Using the hypothetical example above, eight unplanned corrective deployments divided by 100 total deployments results in an 8% deployment rework rate.
DORA's Quick Check frames the metric as the approximate percentage of deployments over the previous six months that were unplanned and performed to address a user-facing bug. That framing is useful for an assessment, but a team building an operational dashboard needs a repeatable classification process.
At minimum, agree on four rules:
- Define what counts as a production deployment and apply that denominator consistently.
- Mark whether each deployment was planned or unplanned at the time it occurred.
- Connect an unplanned deployment to the production incident or user-facing defect it addresses.
- Use the same time window for the numerator and denominator.
The calculation is pretty simple, but classification is the hard part: if teams label corrective deployments differently, their rates will not be comparable. For that reason, avoid inventing a time-based shortcut, such as treating every deployment within a fixed number of hours after an incident as rework, unless the organization explicitly adopts and documents that rule; DORA's definition focuses on why the deployment happened rather than on an arbitrary time window.
What is the difference between change fail rate and deployment rework rate?
Change fail rate measures the proportion of deployments that require immediate intervention, whereas deployment rework rate measures the proportion of all deployments that were unplanned and made because of a production incident. In other words, the first starts with the deployment that caused a problem, while the second starts with the corrective deployment activity created by production problems.
| Question | Change fail rate | Deployment rework rate |
|---|---|---|
| What is counted in the numerator? | Deployments that require immediate intervention | Unplanned deployments made in response to production incidents |
| What is the denominator? | Total deployments in the measurement period | Total deployments in the measurement period |
| What does it reveal? | How often deployed changes need an immediate response | How much deployment activity is reactive corrective work |
| In the hypothetical 100-deployment example | 5 failed deployments = 5% | 8 corrective deployments = 8% |
Neither metric replaces the other: a team can have a relatively low change fail rate and still have a meaningful share of its deployments classified as rework if failures lead to several corrective releases, whereas a failed deployment resolved through a rollback may increase change fail rate without creating multiple subsequent rework deployments.
Reading the two together helps leaders ask better questions. Are failures frequent? When a failure occurs, does it create a long tail of corrective delivery? Is reactive work consuming a growing share of deployment activity even though the failure rate appears stable? Those are different system behaviors and require different investigations.
Why four-metric references are still common
One reason four-metric references remain visible is timing. The fifth metric was added in 2024, so older content and tooling can still reflect the previous structure. Changes in reliability and recovery terminology also contributed to multiple historical versions of the framework.
Public search results confirm that four-metric language remains visible; however, they do not show how many organizations still use that model or whether an organizational transition is underway.
When comparing a dashboard with a current DORA source, check three things before assuming one is wrong:
- the publication or implementation date;
- whether reliability is presented as a dimension, an outcome, or a metric;
- whether recovery is labeled time to restore service or failed deployment recovery time.
Together, these details identify which version of the model a source is using while also preventing historical trend data from being silently reinterpreted under a newer definition.
What the five-metric model changes for engineering leaders
The immediate task is not to discard every four-metric dashboard, but to make definitions explicit and decide how to introduce deployment rework rate without breaking historical interpretation.
A practical transition can include the following steps:
- Keep the existing four-metric time series and record the definitions used for each period.
- Add deployment rework rate with a documented rule for classifying unplanned corrective deployments.
- Rename or annotate recovery metrics if historical data used the broader time-to-restore-service definition.
- Review throughput and instability together instead of treating deployment volume as an isolated success signal.
- Update internal glossaries, dashboard notes, and leadership materials so readers know when the model changed.
Most importantly, use the metrics to diagnose the delivery system rather than rank individual developers, because a rising rework rate is a prompt to examine incident patterns, release practices, test coverage, architecture, or operational feedback, not evidence that a particular person is underperforming.
DevStats offers a DORA metrics report for reviewing delivery signals. Whatever tool you use, the current five-metric model is most useful when every metric has a documented definition, consistent collection rules, and enough context to support a decision.