DORA Metrics Explained - The 4 Keys and How Code Review Drives Them (2026)

Direct answer

DORA metrics measure software delivery performance. Change lead time is defined at dora.dev as the time from committed to version control to deployed in production. Deployment frequency, change fail rate and failed deployment recovery time complete the classic set, and a fifth - deployment rework rate - was added in 2024. We could not verify the elite/high/medium/low band thresholds at primary source and do not repeat them. Verified 2026-10-19.

What are DORA metrics, and are there four or five?

Direct answer: Four in the classic framing, five in dora.dev’s current guide. As of 2026-10-19 that guide lists change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. MTTR was renamed and redefined as failed deployment recovery time in 2023, and deployment rework rate was added in 2024. Most comparison pages are still on the old four. Verified 2026-10-19.

DORA metrics come from the DevOps Research and Assessment programme, a multi-year research effort that surveyed engineering professionals to find what separates high-performing delivery organisations from the rest. The finding that made them famous: throughput and stability are not opposites. The best teams are fast and stable at the same time.

The metric set has changed, and this is the part almost every page in this cluster has missed. Quoting dora.dev’s own history material (verified 2026-10-19): the metrics “have evolved alongside the technology landscape: shifting from the original four keys to the current five-metric model.” Specifically:

Year	Change
2023	”The metric historically known as ‘mean time to recover (MTTR)’ or ‘time to restore service’ was renamed and redefined as failed deployment recovery time”
2024	”The most significant structural change to the metrics occurred in 2024.” DORA researchers found change failure rate was acting as a proxy for rework, so they “introduced a fifth metric: deployment rework rate”

The practical consequence: if you are tracking “MTTR” and comparing it to a band from a 2022-era chart, you are comparing a metric to a threshold that was defined against a different metric. That is a bigger problem than it sounds, and it is the reason the next section exists.

For a compact reference see our DORA metrics glossary entry.

The metrics, defined verbatim from dora.dev

Direct answer: Change lead time is “the amount of time it takes for a change to go from committed to version control to deployed in production.” Deployment frequency is “the number of deployments over a given period or the time between deployments.” Change fail rate is “the ratio of deployments that require immediate intervention following a deployment.” Deployment rework rate is “the ratio of deployments that are unplanned but happen as a result of an incident in production.” All quoted verbatim, verified 2026-10-19.

Metric	Verbatim definition from dora.dev (verified 2026-10-19)	Group
Change lead time	”The amount of time it takes for a change to go from committed to version control to deployed in production.”	Throughput
Deployment frequency	”The number of deployments over a given period or the time between deployments.”	Throughput
Change fail rate	”The ratio of deployments that require immediate intervention following a deployment.”	Instability
Deployment rework rate	”The ratio of deployments that are unplanned but happen as a result of an incident in production.”	Instability
Failed deployment recovery time	Listed among the five metrics; replaced and redefined MTTR in 2023	Instability

Two boundary conditions in the change-lead-time definition carry almost all of its practical weight, and getting them wrong is the most common measurement error in this entire area:

• It starts at “committed to version control”, not at ticket creation. Backlog wait, grooming, and product indecision are explicitly outside the metric. If your dashboard measures from Jira ticket open, you are measuring something else and must not benchmark it against DORA figures.
• It ends at “deployed in production”, not at merged. Merge queue time, release train waits, staged rollouts and manual approval gates are all inside it. A team with a four-hour PR cycle and a weekly release train has a change lead time measured in days, not hours.

Deployment frequency is a proxy for batch size. You can only deploy many times a day if each change is small. See deployment frequency.

Change fail rate measures the quality of what you ship, not the quantity. Note the verbatim wording - “require immediate intervention” - which is narrower than “caused any problem.” See change failure rate.

Deployment rework rate is the 2024 addition and the one nobody has tooling for yet. It counts unplanned deployments caused by a production incident, which is a different number from the count of bad deploys. See lead time for changes and mean time to recovery for the glossary entries, noting that the second is now historical terminology.

Read the set together. A gain in one that quietly damages another is not progress.

What are the DORA elite, high, medium and low thresholds?

Direct answer: We could not verify them at primary source and we will not state them as authoritative. The dora.dev four-keys guide publishes no numerical performance band thresholds (checked 2026-10-19). It directs teams to set a baseline with the DORA Quick Check and notes only that “top performers do well across all five metrics, and low performers do poorly.” Check the current DORA report directly. Verified 2026-10-19.

This section is the reason to read this page rather than the twenty that rank above it.

Every vendor dashboard, every comparison blog and most internal engineering wikis carry a table like “elite deploys on demand, lead time under one hour, change failure rate 0-15%, restore under one hour.” We fetched the dora.dev four-keys guide on 2026-10-19 and it contains no such table. The page names the metrics, groups them into throughput and instability, lists key insights and common pitfalls, and points at the DORA Quick Check for baselining. There are no band numbers on it.

That does not mean band figures were never published - DORA’s annual reports have historically segmented respondents into performance clusters, and those cluster descriptions are where the circulating numbers originate. What it does mean:

1. The numbers you see online are not currently published on dora.dev’s own explainer, so anyone citing dora.dev as the source for a specific threshold should be asked which page and which date.
2. The metric set changed in 2023 and 2024. A recovery-time band defined against MTTR does not cleanly transfer to failed deployment recovery time, and no band exists for deployment rework rate at all in the circulating tables, because the metric postdates them.
3. Cluster boundaries are derived from the respondent distribution of a given year’s survey, which means they move between editions by construction. A 2021 “elite” boundary is a statement about 2021 respondents.

Our position: treat any elite/high/medium/low table you find, including on vendor dashboards, as unverified until you have matched it to a specific DORA report edition and confirmed it uses the current metric definitions. If you need bands for an internal goal, derive them from your own historical distribution instead. That is both more defensible and more useful, and it sidesteps the comparison pitfall DORA itself warns about.

If you find a primary-source band table on dora.dev or in the current report, we want to cite it - the honest state of this page as of 2026-10-19 is that we could not.

How does code review affect DORA metrics?

Direct answer: Review is usually the largest single component of change lead time. Our data on 2,189 merged PRs: open-to-first-review p50 8.7h but p90 212h, while first-review-to-merge is 6.7h at p50 and first-approval-to-merge is 1.1h. The median PR spends 52.7% of its open-to-merge life waiting for the first human. That is pure lead time with no work happening. Verified 2026-10-18.

Here is the connection most DORA write-ups skate past. When you decompose change lead time, the coding portion is small and the waiting portion dominates. The waiting is review latency, and it is squarely within your control without touching a build.

Our full latency distribution, harvested from the GitHub GraphQL API on 2026-10-18 across 12 repositories, excluding bot authors, bot reviewers and self-reviews (published in pull request review time):

Interval	p50	p75	p90	p95	p99
Open to first review	8.7h	66h	212h	482h	1,300h
First review to merge	6.7h	-	-	-	-
First approval to merge	1.1h	-	-	-	-

The p50-to-p90 gap is the finding. A median of 8.7 hours sounds like a solved problem. A p90 of 212 hours - nearly nine days - says one PR in ten sits for over a working week before anyone looks at it. Lead time is driven by the tail, not the median, because a release cannot go out until the slowest change in it has cleared. Any team reporting a healthy median review time and a bad lead time is almost certainly looking at the wrong percentile.

Two further findings from the same dataset:

• There is a 9x spread in median time-to-first-review between sub-50-line PRs and 1,000+-line PRs. Size drives latency directly, which is why PR size is a lead-time lever and not just a quality lever.
• 59.2% of merged PRs had exactly one approver, 14.5% had two, mean 1.08. A blanket two-reviewer policy roughly doubles the waiting component for a benefit nobody has measured.

Disclosed limits on our data: only merged PRs are in frame, which biases latency downward, and Kubernetes and Rust were excluded from the approver analysis as Prow and bors artifacts.

Review affects the stability pair too. Shallow, rushed review lets defects reach production, which drives change fail rate. And the mechanism is measurable: inline review threads per 100 changed lines fall from 1.55 on PRs under 50 lines to 0.085 on PRs over 1,000 lines - an 18-fold drop in scrutiny density - and 52% of merged PRs over 1,000 lines carried zero inline review comments (n=2,896, verified 2026-10-18, published in how big should a pull request be). Honest counterpoint from the same data: absolute comment counts rise with size (Spearman rho +0.355), so large PRs are not ignored, just reviewed far less per line.

So the same practices improve both halves of DORA:

• Smaller PRs get reviewed faster (lower lead time) and more thoroughly per line (lower change fail rate). See pull request size best practices.
• Automated first-pass review collapses the latency tail, shrinking review cycle time that feeds straight into lead time.
• A merge queue keeps high deployment frequency from breaking main, protecting throughput and stability together. See what is a merge queue.

For the measurement side of review specifically, see code review quality metrics and how to make code reviews faster.

How do DORA metrics get misused?

Direct answer: By comparing individuals. DORA measures a delivery system; ranking developers by deployment count destroys it in two steps - people optimise the number, then people stop helping each other because helping does not show in their own column. dora.dev’s own pitfalls list explicitly names competing between teams and making disparate comparisons as anti-patterns. Verified 2026-10-19.

dora.dev publishes a common-pitfalls section, and we fetched it on 2026-10-19. The seven pitfalls it identifies, paraphrased from the page:

1. Setting metrics as a goal - an application of Goodhart’s law, with broad deployment targets that incentivise gaming.
2. Having one metric to rule them all - oversimplifying a complex system with a single measurement instead of using multiple metrics with healthy tension.
3. Using industry as a shield against improving - claiming compliance requirements prevent operational change.
4. Making disparate comparisons - comparing metrics across fundamentally different applications.
5. Having siloed ownership - not sharing metrics across development, operations and release teams.
6. Competing - using metrics to compete between teams rather than drive individual team improvement.
7. Focusing on measurement at the expense of improvement - overinvesting in data collection instead of starting with conversations or the Quick Check.

Note what is and is not on that list. Per-developer comparison is not named explicitly - the page talks about teams and applications. But pitfalls 1, 4 and 6 compose into exactly that prohibition, and the per-developer version is strictly worse than the per-team version for a structural reason worth stating plainly:

Review is the one part of the delivery system where one engineer’s throughput is another engineer’s cost. Every hour you spend reviewing someone else’s PR is an hour your own lead time does not benefit from. The moment lead time becomes an individual metric, reviewing becomes an individually irrational act. You will get exactly what you incentivised: fast individual numbers and a p90 review latency that climbs every quarter. Our 212-hour p90 is what that looks like in the aggregate.

Four more misuses we see repeatedly that are not on DORA’s list:

• Measuring lead time from ticket creation. The definition starts at commit. Including backlog wait makes the number product-managed rather than engineering-managed, and it stops being comparable to anything.
• Measuring lead time to merge rather than to production. Drops the release train, the merge queue, and the staged rollout. This is the most common instrumentation shortcut and it systematically understates the number.
• Reporting the median only. Lead time is tail-driven. Report p50 and p90 or do not report it.
• Treating deployment frequency as a goal. The highest-frequency team in a company is often the one with the smallest blast radius, not the best practices. See the pitfall about disparate comparisons.

How to measure DORA metrics

Direct answer: Compute them from data you already have - deployment events, commit timestamps, incident records - or use a platform that pulls from your Git host and CI. The evaluation question is not whether a tool computes four numbers, which is arithmetic, but whether it decomposes lead time far enough to show that review latency rather than build time is the bottleneck. Verified 2026-10-19.

LinearB is built around this. DORA dashboards with industry benchmarks, pull request cycle time tracking to pinpoint where changes stall, and a free tier covering up to 8 contributors with core engineering metrics. Because it surfaces PR cycle time and bottleneck identification, you can see whether review latency specifically is inflating lead time rather than guessing. Caveat on the benchmark feature: any vendor-supplied “industry benchmark” band inherits the verification problem described above. Ask which report edition and which metric definition it uses.

Graphite attacks the workflow end. PR analytics and cycle-time dashboards expose review and merge bottlenecks, and its stacked-PR workflow plus stack-aware merge queue are designed to raise throughput without sacrificing stability. Stacked diffs are a direct lead-time intervention: they let you keep each PR small while still shipping a large change, which addresses the 9x size-to-latency spread in our data. Two ownership facts worth knowing: Diamond was retired in favour of Graphite Agent on 8 October 2025, and the Cursor acquisition was 19 December 2025 - over two months later, so the rename was not a result of the acquisition (both verified 2026-10-18). graphite.dev now redirects to graphite.com. See what are stacked diffs.

What to instrument if you are building it yourself, in order of value:

1. PR open to first review, at p50 and p90. This is the biggest and most fixable chunk.
2. Merge to production deploy. This is the part teams forget and the part that turns hours into days.
3. Commit to PR open. Often surprisingly large in teams that batch work locally.
4. Deployment count and the gap distribution between deploys, not just a weekly average.
5. Deploys that required immediate intervention, tagged at the time, not reconstructed later.

The fifth is the one nobody does properly, because it requires a human to label a deploy as a failure in the moment. Reconstructed change fail rates are almost always understated.

Can you improve lead time without touching your pipeline?

Direct answer: Yes, and it is the highest-return option available. If the median PR spends 52.7% of its open-to-merge life waiting for a first human, halving that wait moves lead time more than most CI work. The tactics - smaller PRs, automated first pass, SLAs on p90, CODEOWNERS routing - require no pipeline change at all. Verified 2026-10-18.

In priority order by return per hour of effort:

1. Automated first-pass review within minutes of PR open. This is the single most direct attack on the 212-hour p90, because the bot does not have a queue. CodeRabbit posts a summary and inline comments within minutes (Essentials $24/dev/mo annual, covering 1 linked repository - Team $48 covers 5, verified 2026-10-18). Greptile reviews with whole-repo context (Pro $30/seat/mo, credits are per author and do not pool). Anthropic’s Code Review went GA 15 October 2026 for Claude Team and Enterprise and never approves or blocks, so it reduces latency without weakening an approval control.
2. Set the SLA on p90, not the median. A team with an 8-hour median and a 200-hour p90 does not have a review-speed problem on average, it has one in the tail, and only a p90 target makes the tail visible.
3. Cut PR size. 9x spread in median time-to-first-review between sub-50-line and 1,000+-line PRs in our data. Stacked diffs are the mechanism that makes this practical for large changes.
4. Route by CODEOWNERS, not by who is online. A request sent to the wrong person becomes a reassignment, which restarts the clock.
5. Drop blanket multi-reviewer policies. 59.2% of merged PRs already have exactly one approver. Reserve two on high blast-radius paths only.
6. Shorten merge-to-deploy. If you have a weekly release train, no amount of review speed fixes your lead time. This is the one pipeline change worth making before the others.

One thing to get right before you rely on an AI reviewer as a required check, because it is a permanent outage waiting to happen: GitHub’s merge-queue merge_group event is separate from pull_request and push. A required review job triggered only on pull_request never reports on a queued merge, and GitHub’s docs state the status check “will not be triggered… The merge will fail as the required status check will not be reported” (verified 2026-10-18).

And one honest caveat on the AI layer: no party without a commercial stake has published a false-positive rate, precision figure or noise measurement for any shipping commercial AI code reviewer (checked 2026-10-19). The latency benefit is real and mechanical. The quality benefit is vendor-claimed. Anthropic’s own figures for its Code Review - 84% bug detection on PRs over 1,000 lines at under 1% false positives - are vendor-published and unreplicated (verified 2026-10-18). See how to evaluate an AI code reviewer and reduce code review time.

Common mistakes with DORA metrics

• Comparing individuals. Destroys the metric and destroys reviewing, because reviewing is a cost to the reviewer’s own number.
• Citing elite/high/medium/low bands as authoritative. dora.dev’s four-keys guide publishes none (checked 2026-10-19), and the metric set changed in 2023 and 2024.
• Measuring lead time from ticket creation. The definition starts at commit.
• Measuring lead time to merge. The definition ends at deployed in production.
• Reporting the median only. Lead time is tail-driven.
• Chasing one number. Pushing deployment frequency while change fail rate climbs is not a win.
• Still calling it MTTR. Renamed and redefined as failed deployment recovery time in 2023.
• Ignoring deployment rework rate. Added in 2024; almost nothing measures it yet.
• Measuring without acting. DORA’s own pitfall list names overinvesting in data collection instead of starting with a conversation.

How we verified this

Checked at primary source on 2026-10-19:

• dora.dev/guides/dora-metrics-four-keys/ for the verbatim definitions of change lead time, deployment frequency, change fail rate and deployment rework rate quoted in this article, and for the full five-metric list including failed deployment recovery time.
• The same page for the absence of any numerical performance band thresholds. It references setting a baseline with the DORA Quick Check and states that top performers do well across all five metrics and low performers do poorly, with no numbers attached.
• The same page’s “Common pitfalls” section for the seven pitfalls listed above, including “Making disparate comparisons” and “Competing”.
• dora.dev/insights/dora-metrics-history for the 2023 MTTR rename (“The metric historically known as ‘mean time to recover (MTTR)’ or ‘time to restore service’ was renamed and redefined as failed deployment recovery time”) and the 2024 introduction of deployment rework rate (“The most significant structural change to the metrics occurred in 2024… they introduced a fifth metric: deployment rework rate”).

Our own data, harvested from the GitHub GraphQL API on 2026-10-18:

• Review latency (n=2,189 human-authored merged PRs, 12 repositories, bot authors/reviewers and self-reviews excluded): open-to-first-review p50 8.7h, p75 66h, p90 212h, p95 482h, p99 1,300h; first-review-to-merge 6.7h at p50; first-approval-to-merge 1.1h; the median PR spending 52.7% of its open-to-merge life waiting for the first human; a 9x spread in median time-to-first-review between sub-50-line and 1,000+-line PRs; 59.2% of merged PRs with exactly one approver, 14.5% with two, mean 1.08. Published in pull request review time. Disclosed limits: only merged PRs are in frame, which biases latency downward, and Kubernetes and Rust were excluded from the approver analysis as Prow and bors artifacts.
• PR size and scrutiny (n=2,896 human-authored merged PRs, 10 repositories, 104 bot accounts removed, created 17 Apr to 17 Oct 2026): inline review threads per 100 changed lines falling from 1.55 under 50 lines to 0.085 over 1,000 lines; 52% of merged PRs over 1,000 lines with zero inline review comments; absolute comment counts rising with size at Spearman rho +0.355. Published in how big should a pull request be.

Carried from the 2026-10-18 verification pass: CodeRabbit pricing and the 1-repo Essentials cap; Greptile Pro at $30/seat/mo with per-author non-pooling credits; Anthropic Code Review’s 15 October 2026 GA, its never-approves-or-blocks behaviour and its vendor-published detection figures; the Graphite Diamond retirement on 8 October 2025 versus the Cursor acquisition on 19 December 2025; and GitHub’s merge_group required-status-check deadlock.

What we could not verify:

• The DORA elite, high, medium and low band thresholds. They are not published on dora.dev’s four-keys guide as of 2026-10-19. We did not retrieve the current full DORA report, so we cannot confirm whether band figures appear there, under which definitions, or for which metrics. Any band table you encounter should be matched to a specific report edition before use. This is the single largest unverified element in this topic area and we are flagging it rather than filling the gap with a plausible-looking table, which is what most pages in this cluster do.
• Whether failed deployment recovery time band figures exist at all, given the 2023 redefinition. No band exists in circulating tables for deployment rework rate, because that metric postdates them.
• The specific survey sample sizes and years behind any cluster boundaries. Not retrieved.
• Any causal evidence that improving a DORA metric improves business outcomes. The DORA programme’s correlational findings are well known; we did not verify a causal study and are not aware of one.
• No independent false-positive rate, precision figure or noise measurement has been published for any shipping commercial AI code reviewer (checked 2026-10-19), so the review-quality half of the AI-reviewer argument on this page is vendor-claimed while the latency half is mechanical.
• Nothing we found measures deployment rework rate in a commercial tool. If a platform supports it, we could not confirm it.

Disclosure: Gitar is a paid sponsor of aicodereview.cc and was acquired by Sonar in May 2026. It does not appear in this article’s recommendations.

Recommendations

Criteria: which metric change actually moves delivery, and what you can instrument honestly.

Instrument two numbers before you buy anything: PR open to first review at p50 and p90, and merge to production deploy. Those two cover the overwhelming majority of change lead time and both come free from your Git host’s API. If p90 review latency is in the hundreds of hours, you have found your bottleneck and no dashboard purchase will tell you more.

If you want a managed dashboard: LinearB for the metric side, free up to 8 contributors, with the caveat that you should interrogate any built-in “industry benchmark” band for its source edition. Graphite if your problem is the workflow rather than the measurement - stacked diffs plus a stack-aware merge queue attack lead time directly rather than reporting on it.

If you want to move lead time this month: add an automated first-pass reviewer so no PR waits hours for a first signal, and set your review SLA on p90. CodeRabbit if you want the deterministic linter bundle underneath and natural-language custom rules, minding the 1-repo Essentials cap. Anthropic Code Review if you need a reviewer that structurally cannot satisfy a required approval.

For reporting upward: report the set, at team level, as p50 and p90, with the definitions written down - commit to production, not ticket to merge. Derive your own target bands from your own historical distribution rather than importing a table whose provenance you cannot establish. That is more defensible and it avoids the disparate-comparison pitfall DORA itself names.

What not to do: do not put DORA metrics on an individual performance review, do not set a deployment-frequency target, and do not paste an elite/high/medium/low band table into your wiki without first finding the report edition it came from. On 2026-10-19 we could not find one on dora.dev’s own explainer, and neither will the person who asks you where it came from.

Further reading

• Pull Request Review Time - Our Own Data
• Code Review Quality Metrics
• How to Reduce Code Review Time
• How Big Should a Pull Request Be? Our Own Data
• Pull Request Size Best Practices
• What Is a Merge Queue?
• What Are Stacked Diffs?
• DORA Metrics - glossary definition