Delivery metrics: measure rework alongside speed
A team can deploy more often because it ships useful changes or because it keeps repairing broken ones. DORA's five-metric model separates delivery throughput from instability so those two stories do not look identical.
TL;DR: Measure change lead time, deployment frequency and failed deployment recovery time together with change fail rate and deployment rework rate. Track trends for a service with consistent definitions. A higher deployment count alone cannot tell you whether delivery improved.
The symptom this explains
Two teams report the same number: 20 production deployments last week, up from 8. One of them got faster. The other is repairing itself in public, and the deployment count cannot tell you which is which, because a hotfix and a feature ship through the same pipeline and increment the same counter.
That is the specific ambiguity the fifth metric removes, and it is why deployment frequency on its own is a number that can be improved by a service getting worse.
Why the fifth metric matters
Suppose a service has 20 production deployments in a week. Three require immediate intervention. Five deployments are unplanned repairs following production incidents, including repairs for failures that began the previous week.
Those figures answer different questions. The change fail rate is 3 out of 20, or 15 percent. The deployment rework rate is 5 out of 20, or 25 percent. One counts deployments that caused trouble; the other counts deployments spent repairing it. A failed deployment may need several repairs, so the numerators need not match.
This is a worked example, not a benchmark or a claim about a real team.
Define the events before drawing the chart
For each service, record the commit, artifact identity and successful production deployment time. Connect a failed deployment to the incident it caused and the time service recovered. Mark whether a deployment was planned work or an unplanned response to an incident.
The definitions matter more than a dashboard product. Starting the lead-time clock when a pull request merges hides time that committed work spent waiting for review. Counting a failed pipeline run as a successful production deployment measures another process. Keep both signals if useful, but label them separately.
DORA's current delivery model uses five metrics:
| Metric | Question it answers |
|---|---|
| Change lead time | How long from a code commit to successful production deployment? |
| Deployment frequency | How often does the service deploy? |
| Failed deployment recovery time | How long to recover from a deployment that impairs service? |
| Change fail rate | What share of deployments require immediate intervention? |
| Deployment rework rate | What share are unplanned deployments responding to incidents? |
General incident recovery time remains useful for operations. It also includes failures unrelated to a deployment, such as a provider outage. Keep that population separate from failed deployment recovery time so a change in incident mix does not masquerade as a delivery improvement.
Use the metrics to choose work
If lead time rises while build duration stays flat, inspect review and promotion queues. If deployment frequency rises alongside rework, investigate which failures generate repeated hotfixes. If recovery slows, examine rollback compatibility, detection and the time spent securing approval during incidents.
These are starting hypotheses. Compare equivalent services and inspect individual cases before assigning a cause. Ranking engineers by deployment frequency encourages tiny deployments and shifted ownership rather than safer delivery. A service with no failures during the window has no observed failed-deployment recovery time; report that absence instead of inventing a zero-minute recovery.
Check the population before comparing weeks
In a fictional second week, a team has no failed deployments. Its recovery metric is unobserved for that window, not zero. Comparing zero with last week's twenty-minute recovery would manufacture an improvement without a recovery event. Keep counts beside rates and durations.
A deployment spanning regions also needs a consistent event boundary. Record the rollout identity and regional milestones so frequency is not accidentally multiplied by cluster count while lead time ends at whichever region reported first. Choose and document the service-level definition used in the report, then retain lower-level events for diagnosis.
When an incident is attributed to several changes, preserve the evidence and uncertainty. Reclassify corrected records transparently rather than adjusting the numerator until the graph looks favourable. These measures are useful when teams can inspect the underlying releases and choose concrete improvements.
Self-check
A service reports the following two weeks. Week one: 10 deployments, 2 of which needed immediate intervention, 1 unplanned repair, and one failed deployment that took 45 minutes to recover. Week two: 20 deployments, 3 needing immediate intervention, 8 unplanned repairs, and no failed deployments at all. The team's summary says deployment frequency doubled, change fail rate fell from 20 percent to 15 percent, and recovery time improved to zero.
Work out which of those three claims survive, what the rework figures say that the fail rate does not, and what you would ask for before accepting any of it. Work it through before reading on.
Deployment frequency did double, and it is the least informative of the three. Change fail rate did fall on the stated definition: 2 / 10 = 0.20 against 3 / 20 = 0.15. But look at what the denominator is doing. Week two's denominator grew by 10 deployments, of which 7 were extra unplanned repairs, so the rate fell partly because the work that inflated the count was remedial. A rate whose denominator includes repairs will improve as a service becomes less stable, provided each repair itself deploys cleanly.
The rework rate is the figure that contradicts the summary. Week one is 1 / 10 = 10 percent; week two is 8 / 20 = 40 percent. So four in ten deployments in week two existed to repair something, which is the opposite story to the one the team is telling, and it is invisible in the other four metrics.
The recovery claim does not survive at all, and it is worth being exact about why. Week two had no failed deployments, so there is no failure-to-restoration duration to report: the metric is unobserved, not zero. Comparing an absent measurement against week one's 45 minutes manufactures an improvement from a missing sample, and reporting it as zero is how a metric stops being evidence. The honest report is 45 minutes from one event in week one and no observation in week two, with the counts printed beside the durations so nobody reads a single event as a trend.
What to ask for before accepting any of it is the classification behind the repairs: which incidents those 8 deployments were responding to, whether several of them repaired the same underlying failure, and whether any incident began in the previous week. One failure needing five hotfixes and five separate failures produce the same rework count and call for entirely different work. And for the single 45-minute recovery, whether detection or approval dominated it, since those have different fixes.
Next: deploying is not releasing separates the two events these metrics count, and error budgets and burn rate gives instability a threshold rather than a trend line.
Sources: DORA's delivery metrics, how the definitions evolved. These definitions were checked for the September 2026 review.