DORA Metrics

DORA metrics describe software delivery performance. The program’s January 2026 guidance uses five metrics, extending the older four-key model. Its history explains the narrower focus of failed deployment recovery time compared with all-cause MTTR. An organization may track both, provided their event populations and measurement boundaries remain explicit.

DORA groups the five measures into throughput, concerning the flow and recovery of changes, and instability, concerning failed or corrective deployments. The table follows its January 2026 definitions.

The five, as defined

Group	Metric	Definition
Throughput	Change lead time	“The amount of time it takes for a change to go from committed to version control to deployed in production”
	Deployment frequency	“The number of deployments over a given period or the time between deployments”
	Failed deployment recovery time	“The time it takes to recover from a deployment that fails and requires immediate intervention”
Instability	Change fail rate	“The ratio of deployments that require immediate intervention following a deployment,” likely resulting in “a rollback of the changes or a ‘hotfix'”
	Deployment rework rate	“The ratio of deployments that are unplanned but happen as a result of an incident in production”

Two details in those definitions are easy to read past and change what the numbers mean.

Change lead time starts at the commit. Time a request spent waiting for prioritization, specification, or approval before anyone wrote code is outside it. That is a defensible boundary for a metric about delivery, and a serious error if you present the figure as the time from request to value. Measuring that wider span is a different exercise — see value stream mapping.

The instability metrics count different events. Change fail rate concerns the deployment that required immediate intervention. Deployment rework rate concerns an unplanned deployment made because of a production incident. A recovery deployment can also fail, so the categories are not mutually exclusive for every event.

So a single incident can produce a numerator in one, the other, both, or neither, and it is worth walking through why.

• Fixed by an unplanned deploy. The causing deployment required immediate intervention, so it counts toward change fail rate; the corrective deployment was unplanned and caused by an incident, so it counts toward rework rate. Two different deployments, two different metrics.
• Fixed without a new deployment. Suppose an operator changes an existing dynamic flag at runtime and no deployment occurs under the service’s declared counting rule. The failed deployment still counts toward change fail rate, but this recovery adds no rework deployment. If changing a flag or configuration instead produces a new release or redeployment, count that event according to the same rule; an incident-driven unplanned deployment can belong in rework.
• Caused by something other than a deployment — a dependency failure, a traffic spike. Any unplanned deployment to resolve it counts toward rework rate while no deployment failed.

The delay before discovery is a separate axis from all of this. A release that quietly degraded something and was found two days later may or may not meet “require immediate intervention,” and that is a question about how your organization defines the threshold and how far back it attributes a failure — not something the two-day gap settles by itself. Which is why both metrics need their numerator, their denominator, and an attribution window written down before anyone compares two periods.

Why both groups, and not a choice between them

DORA reports that teams performing well on delivery speed also tend to perform well on stability. The measures should therefore be read together, rather than treating slow delivery as evidence of care.

In that discussion, DORA cites David Farley’s argument that better engineering can improve quality and speed over the long term. This does not prove that an individual review or gate has no delay cost. Evaluate the failure it prevents, the wait it adds, and alternatives that could provide the same protection.

The measures describe outcomes of delivery practices and are associated with later organizational performance and employee well-being. They guide investigation but do not identify a specific intervention on their own.

How each one is gamed

DORA warns that broad numerical quotas can reward moving a metric instead of improving delivery. The examples below illustrate distortions to check for when interpreting a trend.

Write down event definitions before setting a baseline, and inspect unexpected changes in the underlying events. A favorable number can result from a different counting rule.

• Deployment frequency — repeatedly redeploy an unchanged artifact without an operational purpose, or count several steps of one rollout separately. Frequency can rise without faster useful feedback. Independently validated small changes are different: genuine batch reduction can improve delivery.
• Change lead time — hold work outside version control until it is nearly ready, then commit and deploy. The clock starts at the commit.
• Change fail rate — narrow what counts as requiring immediate intervention. If a fix within the hour is just “the next deployment,” the rate falls.
• Failed deployment recovery time — record the incident as starting when someone acknowledged it rather than when it began.
• Deployment rework rate — log the unplanned fix as a planned release.

There can be legitimate choices about measurement boundaries, but they should be declared and applied consistently. Retroactively narrowing failures or relabeling unplanned fixes to improve a score changes the evidence. Read the five measures together and inspect event samples; no second metric is guaranteed to expose every distorted count.

A team can set an improvement goal for its own service while checking failure rates, feedback, and user outcomes. The risk grows when rewards attach to a number without its context. Pair the goal with relevant checks and investigate when the metric improves but the intended outcome does not.

Four more pitfalls come from the same source and each has a clear failure mode.

• Making disparate comparisons. DORA recommends one application or service as the measurement scope. Compare its history under consistent definitions and use similar contexts for benchmarks. For a fleet view, disclose the population and weighting and show the distribution; changing the service mix can move an aggregate without any service improving.
• Siloed ownership. Development, operations, and release teams should share the five measures. Giving throughput to one group and instability to another can reward improvements that transfer costs across the boundary.
• Competing. Use the measures to improve the service over time rather than rank teams whose circumstances differ.
• Measuring instead of improving. DORA recommends starting with conversations or a self-assessment when precise integrations would delay action. Instrumentation can support improvement, but its duration or completeness does not establish that delivery outcomes changed.

DORA also warns against treating industry constraints as proof that improvement is impossible. Compliance affects how changes can be delivered; teams can still investigate unnecessary waiting and test compatible improvements.

What they do not measure

One limit sits outside the published list and matters more than any of them: nothing here says whether the change was worth making. A team can post excellent numbers across all five while shipping features nobody uses. The metrics describe the delivery system, which is what they claim to describe — reading them as a measure of value delivered is a substitution the research never made.

Establish a baseline, discuss friction, choose a significant constraint, and test an improvement. A value stream map helps connect the measurements with actual work. smaller batches are one candidate, not the predetermined result of every map. The relationship is explored in Six Weeks of Waiting, Two Days of Work.

References

• DORA — Software delivery performance metrics (January 5, 2026)
• DORA — A history of software delivery metrics
• Pete Hodgson — Feature Toggles