DORA Metrics Explained (2026): The Five Metrics, Benchmarks and AI

Every few months someone sends me a dashboard with four green DORA tiles and asks whether their team is now elite. My first question is always the same: what counts as a deployment here? The answer usually explains the colour of the tiles better than anything the team did. DORA metrics are the most useful five numbers in software delivery and also the easiest to fool yourself with, and the definitions moved twice in the last three years: recovery time was redefined in 2023, a fifth metric arrived in 2024, and the 2025 report dropped the elite, high, medium and low tiers people still quote. This post explains the five DORA metrics as DORA defines them today, what the benchmarks actually say, how to measure them without lying to yourself, and what the research found when AI coding tools entered the pipeline.

What are the five DORA metrics in 2026?

DORA's own metrics guide, last updated 5 January 2026, describes "the current five-metric model" and splits it into two groups. Throughput is about how fast change moves; instability is about how well deployments go.

Metric	DORA's definition (abridged)	Group	Typical data source
Change lead time	Time for a change to go from committed to version control to deployed in production	Throughput	Git history plus deploy events
Deployment frequency	Number of deployments over a period, or time between deployments	Throughput	CD tool, GitHub Deployments API
Failed deployment recovery time	Time to recover from a deployment that fails and requires immediate intervention	Throughput	Deploy events, incident tracker
Change fail rate	Ratio of deployments that require immediate intervention (rollback, hotfix)	Instability	Deploy events linked to incidents or reverts
Deployment rework rate	Ratio of deployments that are unplanned and happen because of an incident in production	Instability	Deploys tagged as hotfix or incident-driven

Source: dora.dev metrics guide. The groupings are DORA's, not mine.

Two things in that table surprise people. Recovery time now sits under throughput, not stability. Steve Fenton's CD Foundation write-up gives the reasoning: teams with short lead times can push a fix through the normal pipeline without an expedited process, so recovery speed behaves like delivery speed. And rework rate is a deployment metric, not a ticket metric. It counts unplanned deploys made because production broke, divided by all deploys: three unplanned out of ten is 30 percent.

From four keys to five: what changed and why

The "four keys" phrase is still everywhere, including in vendor dashboards, so the history matters. DORA's history page gives the sequence:

• 2014: four variables (deployment frequency, lead time, mean time to recover, change fail rate). Change fail rate did not correlate with the others at first, so the early performance construct used three.
• 2015: the throughput and stability split, and the finding that speed and stability are not a trade-off.
• 2018: availability added, and the term became software delivery and operational performance.
• 2021: availability broadened to reliability. DORA now says the 2021 report wrongly called reliability the "fifth metric".
• 2023: MTTR replaced by failed deployment recovery time, to separate failures caused by your changes from outages you did not cause.
• 2024: deployment rework rate introduced as the fifth metric.

DORA's 2025 year in review says it has "officially evolved the four software delivery performance metrics into five metrics". The 2023 change is the one I see teams miss most. If your recovery number includes a cloud provider outage or a DDoS, you are measuring your luck, not your delivery system. The current definition only starts the clock when one of your deployments fails.

DORA benchmarks: elite clusters in 2024, seven team profiles in 2025

The tiers people quote come from the 2024 Accelerate State of DevOps report. Octopus Deploy's summary of the 2024 clusters lists them as follows.

2024 cluster	Deployment frequency	Change lead time	Change fail rate	Recovery time
Elite	On demand	Less than a day	5%	Less than an hour
High	Daily to weekly	1 day to 1 week	20%	Less than a day
Medium	Weekly to monthly	1 week to 1 month	10%	Less than a day
Low	Monthly to biannually	1 to 6 months	40%	1 week to 1 month

Source: Octopus Deploy, 2024 DevOps performance clusters. The same summary puts elite at under 20 percent of respondents, deploying 182 times more often than low performers, with 127 times faster lead times and 8 times lower change fail rates.

Look at the change fail rate column: high performers fail 20 percent of changes and medium performers 10 percent. That inversion is not a typo. The clusters are statistical groupings across all metrics together, and the high group trades more failures for much more frequent delivery. It is a good reason not to treat any single column as a target.

The 2025 report, renamed State of AI-assisted Software Development and based on nearly 5,000 respondents, stopped ranking teams on one axis. It ran a cluster analysis that produced seven team profiles combining delivery throughput, instability, team and product performance, friction and burnout. The prevalence figures below come from a secondary summary of the report chapter, since Google's announcement names only two profiles.

The same newsletter's 2025 benchmark summary gives partial per-metric distributions: 16.2 percent of respondents deploy on demand, 9.4 percent have lead times under an hour, 8.5 percent have a change fail rate of 2 percent or less, 21.3 percent recover from a failed deployment in under an hour, and 7.3 percent have rework rates below 2 percent. I could not get the full bucket tables from a primary source, so treat these as indicative. The point stands either way: under-an-hour lead time is rare, and most teams sit in the middle of every distribution.

How to measure DORA metrics honestly

DORA's guide says the metrics are "best suited for measuring one application or service at a time", and that blending them across teams is misleading. That one sentence rules out most of the org-wide leaderboards I have seen. The rest of honest measurement is a short list of decisions you write down before you build a dashboard:

1. Define a deployment. A production change that users can be affected by. A staging deploy is not one; a feature flag flip arguably is, if it is how you release.
2. Pick start and end events for lead time. DORA starts at commit. Many tools start at PR merge because it is cleaner data. Either is fine if you say which.
3. Use medians and a high percentile, not means. One PR that sat for a month will drag a mean around for a quarter.
4. Decide what links a failure to a deployment. A revert, a hotfix label, an incident ticket with the deploy SHA. Without a link, change fail rate is a guess.
5. Count unplanned deploys as rework. Tag the deploy itself (a hotfix label on the PR, a workflow input) at the time, because nobody reconstructs this accurately later.

Most of the raw data is already in your Git host. On GitHub, every workflow job that targets an environment creates a deployment object by default, according to the Actions docs, and the Deployments REST API lists them per environment:

# List the latest production deployments for one service (gh CLI, REST API version pinned).
# Each row: deployment id, short SHA, ref, creation time.
gh api \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  "repos/OWNER/REPO/deployments?environment=production&per_page=20" \
  --jq '.[] | [.id, .sha[0:7], .ref, .created_at] | @tsv'

When I ran that against a busy public repository, the same SHA appeared three times within one second: a matrix job creates a deployment per leg. Deduplicate by SHA and keep only deployments whose latest status is success, or your deployment frequency triples for free. The full pipeline, with SQL for all five metrics, is in the companion guide on how to measure DORA metrics from GitHub.

How DORA metrics get gamed (and how to spot it)

DORA's guide is blunt about this: setting the metrics as goals "increases the likelihood that teams will try to game the metrics", which is Goodhart's law with a citation. The guide's list of pitfalls includes focusing on a single metric, comparing unlike applications, siloed ownership and turning the numbers into a competition. In practice, the gaming I have seen looks like this:

• Deployment frequency inflated by empty deploys. Config-only or no-op pipelines that count as deploys. Check: deploys per week against PRs merged per week. If deploys outnumber changes, ask why.
• Lead time shortened by moving the start. Measuring from "PR approved" instead of first commit hides the review queue, which in 2026 is where most of the time goes.
• Change fail rate lowered by reclassification. A broken deploy becomes a "minor issue" rather than an incident, or a fix ships as a normal PR. Rework rate exists partly to catch this: hiding failures moves them into unplanned deploys.
• Recovery time cut by closing tickets early. The incident is closed when the rollback starts, not when users are fine. Tie the end of the clock to a deploy event or an SLO recovering, not a ticket state.
• Batch splitting for appearances. Small batches are the goal, but a large change cut into ten dependent PRs that all deploy at once improves nothing.

The defence is the design of the set itself. The five metrics pull against each other: push frequency without discipline and instability rises; slow down to avoid failure and throughput drops. A team that improves one metric while another quietly worsens is the signal to have a conversation. Pairing the numbers with an error budget, as in SLO burn rate alerting, gives the instability side a user-facing anchor that is much harder to reclassify.

What DORA found about AI and these metrics

AI coding tools are the reason DORA metrics are back in board decks. The 2024 report, announced on 22 October 2024, estimated that increased AI adoption came with a 1.5 percent decrease in delivery throughput and a 7.2 percent reduction in delivery stability, while documentation quality, code quality and review speed improved. In the 2025 report, 90 percent of respondents used AI at work and the throughput relationship turned positive for the first time, but "AI adoption does continue to have a negative relationship with software delivery stability". DORA's summary of the whole effect is that AI "amplifies what's already there".

DORA's 2026 ROI work assumes the same direction. InfoQ's coverage of the ROI of AI-assisted Software Development report notes that its sample calculator assumes change failure rate rising from 5 to 6 percent after adoption, worth $344,000 of downtime in the example. As of today, dora.dev's publications page lists no 2026 annual survey report, so there is no newer cross-industry number to quote.

My reading for engineering teams: AI makes the throughput metrics cheaper to move and the instability metrics more important to watch. More PRs per developer is not a DORA metric. If merged PRs double and deployment frequency does not, the bottleneck is review or release, and if change fail rate and rework rate creep up together, the extra volume is being paid for in production. I wrote about the wider picture in why DevOps still matters in the AI era; the short version is that small batches, trunk-based work and fast rollback are now load-bearing, which is the same advice as in my post on trunk-based branching.

FAQ

What are the 5 DORA metrics?

Change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. DORA groups the first three as throughput and the last two as instability. Rework rate was added in the 2024 report; recovery time replaced MTTR in 2023.

What is the difference between change fail rate and rework rate?

Change fail rate is the share of deployments that needed immediate intervention, such as a rollback or hotfix. Rework rate is the share of all deployments that were unplanned and made because of a production incident. One measures how often you break things; the other measures how much of your delivery capacity goes to fixing them.

Is MTTR still a DORA metric?

No. Since 2023 DORA uses failed deployment recovery time, which only counts recovery from failures caused by your own deployments. Outages from a cloud provider or an attack are excluded, because they say little about your delivery process.

What is a good DORA score in 2026?

There is no official one. The 2024 elite cluster deployed on demand with lead times under a day, a 5 percent change fail rate and recovery under an hour, but the 2025 report replaced tiers with seven team profiles. DORA's advice is to compare a service with its own past, not with other teams.

This quarter I would do three unglamorous things on any team that asked me about DORA: write a one-page definition of deployment, failure and rework per service and get the team to agree to it; wire deploy events and revert or hotfix labels into a small SQL table, not a vendor dashboard; and add rework rate alongside change fail rate, because with agents writing more of the code, unplanned work is where the cost will show up first. (PandaStack, the microVM cloud I build and run alone, is my company, and small reversible deploys are most of how one operator keeps it boring.) None of this needs a platform purchase. It needs the definitions written down before the first chart is drawn.

Related: DevOps Still Matters in 2026: AI Cut Delivery Stability 7.2%, Then Doubled Merged PRs and Added 91% to Review Time, Incident Management in 2026: Opsgenie Ends April 2027, AI SREs Arrive and Platform Engineering vs DevOps vs SRE in 2026: 90% Now Have a Platform.