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.
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.
Self-check
A team doubles deployments while planned feature deployments remain unchanged. Which metric helps explain the increase? What data would distinguish quicker recovery from a week that simply had fewer failures?
Sources: DORA's delivery metrics, how the definitions evolved. These definitions were checked for the September 2026 review.