DORA metrics 2026: how to calculate all five

A dashboard says deployment frequency doubled this quarter. Then someone notices that the pipeline now also reports staging deployments and counts every retry, and the real number turns out to be flat. The counting changed while delivery stayed where it was.

DORA is easy to quote and hard to compute: the official page defines each metric in one sentence and leaves the arithmetic to you. This guide supplies the formulas, runs all five on a small ledger and writes down the counting rules that decide whether your number means anything.

What are the five DORA metrics in 2026?

There are five DORA metrics: three of throughput and two of instability. Calculate them from the production deployments of one application or service and read them together instead of optimizing one. The definitions below come from the DORA metrics guide, last updated on 2026-01-05. The last column is the formula this article uses, because the guide does not publish one.

Two details in this table are often missed. Recovery time sits in the throughput group, and there are five metrics: the history page records that mean time to recovery was renamed and redefined as failed deployment recovery time in 2023, so that failures with an external cause, such as a data center outage, stop counting. Rework rate arrived in 2024.

flowchart TD
  accTitle: The five DORA metrics and their shared source
  accDescr: A ledger of production deployments for one service, with deploy time, commit times, outcome and restoration time, feeds five metrics. Throughput: change lead time, deployment frequency and failed deployment recovery time. Instability: change fail rate and deployment rework rate.
  L[(Production deployments of one service: deploy time, commit times, outcome, restored time)]
  L --> T[Throughput]
  L --> I[Instability]
  T --> T1[Change lead time]
  T --> T2[Deployment frequency]
  T --> T3[Failed deployment recovery time]
  I --> I1[Change fail rate]
  I --> I2[Deployment rework rate]

DORA also says the metrics suit “one application or service at a time”. A single organization-wide frequency figure mixes systems that have nothing to do with each other.

How do you calculate each DORA metric?

Each metric reduces to a count or a median over production deployment records. Every formula needs the same inputs: a deploy timestamp, commit timestamps, an outcome flag and, for failures, a restoration time. The table above has the formulas; the choices behind them deserve a sentence each.

Lead time and recovery time use the median because both distributions have long tails. The DORA guide does not say median or mean. One widely used implementation measures lead time from the commit timestamp to the end of the deployment and takes the median across deployments, the same choice. Keep the mean next to it at first: a mean far above the median tells you a few changes waited a very long time.

Recovery time needs a start point. We recommend starting the clock when the failed deployment reached users and stopping it when the service was restored, whether by rollback, fix or flag. Starting at detection gives shorter numbers and hides slow alerting. Either works if you pick one and keep it.

What does a worked example look like with 18 deployments?

Take one service over 28 days. The pipeline logged 24 deploy events. Five went to staging and were excluded. One production run failed in the pipeline before any traffic moved and was re-run twelve minutes later, so it counts once. That leaves 18 production deployments. This ledger is illustrative, built to show the arithmetic, and each deployment carries one change.

flowchart TD
  accTitle: Counting deployments in the worked example
  accDescr: 24 deploy events in the pipeline. 5 staging deployments are excluded, leaving 19. One production run failed before any traffic moved and was re-run, so the pair counts once, leaving 18 production deployments.
  A[24 deploy events in the pipeline] --> B{Did it reach production?}
  B -->|no: 5 staging runs| X[Excluded]
  B -->|yes: 19 runs| C{Did traffic move?}
  C -->|no: failed in the pipeline, re-run 12 min later| Y[Counted once with its re-run]
  C -->|yes| D[18 production deployments]
  Y --> D

Now the five calculations.

xychart-beta
  accTitle: Lead time per deployment in the worked example
  accDescr: Bar chart of lead time in hours for deployments D01 to D18, from 0.5 to 70 hours, with a flat line at the median of 15 hours.
  title "Change lead time per deployment (illustrative)"
  x-axis ["D01", "D02", "D03", "D04", "D05", "D06", "D07", "D08", "D09", "D10", "D11", "D12", "D13", "D14", "D15", "D16", "D17", "D18"]
  y-axis "Hours" 0 --> 75
  bar [20, 6, 52, 14, 9, 0.5, 30, 18, 7, 26, 11, 70, 16, 5, 22, 2, 40, 12]
  line [15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15]

Three things in this small ledger repay a second look. Change fail rate and rework rate differ (3 against 2) because the flag change on D11 fixed a failure without a deployment, so it counts as a failure and not as rework. The remediation deployments D06 and D16 sit inside the 18, because they are deployments like any other. And the recovery median of 35 minutes rests on three events, one of them far longer than the other two, so report the count and the slowest case beside it.

A database outage that month with no preceding change would appear in none of these numbers. It belongs in reliability reporting, next to your SLOs.

What counts as a deployment?

For DORA purposes, a deployment is a change reaching production. Everything else is a decision you make once and write down, because a pipeline will count whatever it logs. These are the rules we recommend. The DORA guide settles few of them, so treat them as arguable defaults.

The last row causes the most damage. If incident data stopped flowing from your on-call tool in week three, change fail rate drops to 0% for that week and the trend improves. Reconcile the deployment list against known incidents before you trust a good month.

What happened to elite, high, medium and low?

The current DORA metrics guide publishes no elite, high, medium or low thresholds. Its closest statement is that top performers do well across all five metrics and low performers do poorly. Older articles and several vendors still sell the four tiers with fixed numbers.

Thresholds are not part of the current guide, and the history page does not mention them either. The 2025 DORA announcement describes a cluster analysis that produced “seven common team profiles or archetypes”, each with its own mix of performance, stability and well-being. It names two, “Foundational challenges” and “Harmonious high achievers”. The full report details each profile in its chapter on the seven team profiles.

Benchmarks from tooling vendors come from that vendor’s customers and definitions. Your own six-month trend, computed with fixed rules, says more than your position on someone else’s table.

Is code churn the same as deployment rework rate?

Code churn and reverted commits are code-level signals, while deployment rework rate is a deployment-level ratio, so they are not interchangeable. Rework rate asks how many of your production deployments existed only because of an incident. Churn asks how much recently written code was changed again, which also happens in healthy refactoring and normal review.

Churn is still worth watching. In a study of 806 open-source projects that adopted Cursor, presented at MSR 2026, static analysis warnings rose 30% and code complexity rose about 40%, and both stayed up after the speed gains faded within two months. A 2026 preprint found that merged pull requests from AI coding agents received a verified follow-up fix within 30 days at 1.62 times the odds of human pull requests in the same repositories. Both studies cover open-source projects and are correlational. Use them as a reason to look, then check your own incident-driven deployments. If you only have reverts, label the figure “revert rate (proxy)”.

Do DORA metrics show whether AI is helping?

They show what happened to delivery, and the 2025 data points in two directions. The DORA 2025 research drew on nearly 5,000 technology professionals and more than 100 hours of qualitative data. In Google Cloud’s summary, 90% use AI at work, more than 80% believe it raised their productivity and 30% report little or no trust in AI-generated code. Unlike the previous year, AI adoption now has a positive relationship with software delivery throughput and product performance, and it keeps a negative relationship with delivery stability.

In practice, a lead time that falls after an AI rollout should send you to change fail rate and rework rate in the same weeks. DORA’s own framing is that AI amplifies what an organization already has. A team with a slow review queue and thin tests then pushes more changes into that same queue.

Attribution is the hard part. A shorter lead time can come from smaller tickets, a new release process or a team change. To say anything about AI you need usage data next to delivery data, split by team and period. The companion article on measuring AI productivity covers that join, including what review and rework do to the apparent saving.

If a metric moves, where should you look?

When one DORA metric moves, the other four and the underlying records tell you why. Use this table for a first triage and then open the records, because every row can also be a counting artifact.

Frequently asked questions about DORA metrics

What are the 4 vs 5 DORA metrics?

Older material lists four, ending with mean time to recovery. The current model has five: recovery was redefined in 2023 as failed deployment recovery time, and deployment rework rate was added in 2024.

How do you calculate change fail rate?

Divide the deployments that required immediate intervention by all production deployments in the same period and service. In the ledger above that is 3 ÷ 18 = 16.7%. The numerator needs a rule for what “immediate intervention” means (rollback, hotfix, flag disabled), applied the same way every month.

Does a staging deployment count?

No. Lead time is defined up to deployment in production, so staging, QA and preview deploys sit outside all five metrics. Count them in a separate pipeline report if you want them.

Should you use mean or median for lead time?

The DORA guide does not prescribe one. We recommend the median, with the mean beside it while you learn the distribution.

What is a good DORA score?

The current guide publishes no numeric thresholds. It says top performers do well across all five metrics. Compare a service with its own trend under fixed counting rules before comparing it with anyone else.

Can DORA metrics measure individual developers?

No. DORA defines them for an application or service, and a deployment is a team outcome. Review, design and incident work shape the numbers without appearing under one person’s name.

How often should you review DORA metrics?

Review them monthly with the people who run the service. Failure and recovery counts are too small to read week by week.

What should you do first?

Pick one service and fill in a ledger like the one above from your own pipeline for the last 28 days. Drop the staging events, merge the retries, link each failure to its restoration time and reconcile the list against your incident history. If any of those steps is hard, you have found your real first project.