DORA Metrics

DORA metrics are a small set of measures of how well an organization delivers software changes, produced by the DORA research program. They are widely cited as “the four keys,” and that name is now out of date: the published guidance describes “shifting from the original four keys to the current five-metric model,” including “the move from MTTR to Failed Deployment Recovery Time.” Definitions below follow dora.dev, checked in September 2026 — this is a set that has changed before and may change again.

The five are grouped into two, and the grouping is the most useful thing about them. Throughput is “a measure of how many changes can move through the system over a period of time.” Instability is “a measure of how well the software deployments go.”

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.

And the two instability metrics count different events, which is the detail most summaries get wrong. Change fail rate is about the deployment that caused trouble — the ratio of deployments “that require immediate intervention following a deployment,” which likely results in “a rollback of the changes or a ‘hotfix’.” Deployment rework rate is about a different deployment: the unplanned one you made in response, “the ratio of deployments that are unplanned but happen as a result of an incident in production.”

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 deploying — a flag flipped, a configuration change, capacity added. Intervention was still immediate and still required, so the causing deployment counts toward change fail rate; there is no rework deployment to count at all.
• 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

The finding that makes the set worth attention is that the groups do not trade against each other: “speed and stability are not tradeoffs. In fact, we see that the metrics are correlated for most teams. Top performers do well across all five metrics, and low performers do poorly.”

The guidance quotes David Farley for the choice that actually exists — “the real trade-off, over long periods of time, is between better software faster and worse software slower.” Which is worth having to hand when someone defends a slow release process as the careful option.

There is also a subtlety in what kind of signal these are. The same five values act as “leading indicators for organizational performance and employee well-being” and as “lagging indicators for software development and delivery practices.” They point forward at organizational outcomes and backward at the practices that produced them. What they never do is tell you what to change.

How each one is gamed

The published pitfalls put this first, and name the mechanism: “setting metrics as a goal. Ignoring Goodhart’s law and making broad statements like, ‘Every application must deploy multiple times per day by year’s end,’ increases the likelihood that teams will try to game the metrics.”

It is worth being concrete about how, because each metric has an obvious exploit and a target makes finding it rational.

• Deployment frequency — split one deployment into five. The number rises; nothing else changes.
• 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.

None of these requires dishonesty; each is a defensible classification choice that happens to move the number. That is why the guidance warns against “having one metric to rule them all” — teams should hold “multiple metrics, including some with a healthy amount of tension between them,” which the throughput-and-instability split provides only if all five are looked at together.

It is also why targets need care rather than a blanket refusal. The documented risk is that a target “increases the likelihood that teams will try to game the metrics,” and that risk is at its sharpest when the number attaches to someone’s standing, funding or pay. A team setting itself a goal for its own deployment frequency, on its own service, and reading it next to its change fail rate is doing something different — it is the ordinary use of a leading indicator. If you set one, pair it with the metric that would deteriorate if it were gamed, and treat an improving number with a flat outcome as a reason to look at the definitions rather than to celebrate.

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

• Making disparate comparisons. The metrics are “best suited for measuring one application or service at a time,” and comparing “a mobile app and a mainframe system” produces a meaningless ranking. The objection is to comparing across differing contexts, not to comparison itself: a service against its own history, or against a benchmark for teams in similar circumstances, is how you learn whether a number is good. Blending across an organization fails for the same reason a mixed ranking does — and if you must report a fleet figure, state the population, whether services are weighted, and the distribution rather than the mean, since the average moves when the mix of services changes.
• Siloed ownership. Sharing all five “across development, operations, and release teams fosters collaboration and shared ownership”; splitting throughput to one group and instability to another “can lead to friction and finger-pointing,” since each can then improve its own number at the other’s cost.
• Competing. The stated goal is “to improve your team’s performance over time, not to compete against other teams or organizations.”
• Measuring instead of improving. Building integrations for precise figures “might not be worth the initial investment”; starting with conversations or a self-assessment is recommended. A team a quarter into instrumentation has improved nothing yet.

The guidance also names one excuse specifically — “using industry as a shield against improving,” where teams in regulated industries treat compliance as proof the status quo cannot change. Compliance constrains how you deliver; it does not fix how long you wait.

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.

Used properly they are a compass rather than a scoreboard, which is also how the recommended improvement loop treats them: set a baseline, talk about the friction points, then “commit to making an improvement in the most significant constraint or bottleneck,” plan it, do it — “there are very few shortcuts” — and check. Finding that constraint is the job of a value stream map, and the most common thing it recommends is smaller batches. How the pieces fit together is worked through in Six Weeks of Waiting, Two Days of Work.

Reference: DORA, DORA’s software delivery performance metrics (documentation dated 2026-01-05, checked September 2026).