DORA Metrics: What They Show and What They Don't

DORA measures how work moves through your delivery system. It does not measure individual developers, whether you're building the right product, or how your engineers feel about their jobs. Teams get into trouble when they forget the difference.

Two things also changed recently that most guides haven't caught up with. The four metrics became five. And AI adoption is breaking the historical link between speed and stability, which makes a good DORA scorecard harder to read than it was two years ago.

What does DORA actually measure in 2026?

Five metrics, split across two dimensions: throughput and instability.

Rework rate arrived in the 2024 report. It correlates strongly with change failure rate, which is the point — DORA's research found that stability and rework are both quality indicators, and tracking only one leaves a gap.

There is also reliability, added in 2021 as a quasi-metric. It isn't a single number. It's whether you're meeting the service level objectives you set, seen from the user's side.

Worth noting for anyone citing the research: in 2025 DORA stopped expanding its own acronym and renamed the annual report from Accelerate State of DevOps to the State of AI-assisted Software Development. If you're linking to "the DORA report" in a deck, check which one you mean.

What do these metrics genuinely tell you?

They tell you where work gets stuck.

That is a narrow claim, and it's the correct one. A rising lead time with flat deployment frequency usually means work is queuing somewhere — code review, QA, a release train. A high change failure rate with fast recovery is a different organisation from one with a low failure rate and slow recovery. The four original metrics were designed as a system-level diagnostic, and the research behind them, starting in 2014 and synthesised in Accelerate in 2018, was always about organisational performance rather than individual output.

Used this way, they're one of the few things in engineering measurement with a real evidence base behind them.

What can't DORA metrics tell you?

Individual productivity. DORA is measured at the level of an application or service delivery pipeline. Splitting it by developer produces numbers that look meaningful and aren't. A developer working on a legacy service with a two-week release train will always look slower than one shipping to a greenfield service, and the difference says nothing about either of them.

Whether you're building the right thing. A team can hit elite deployment frequency shipping features nobody uses. DORA measures the pipeline, not the product. This is the most common failure I see: an engineering org optimises delivery metrics for a year, hits every target, and the business impact doesn't move.

How the work feels. Cognitive load, interruption, unclear ownership, waiting for someone else's approval — none of this appears in DORA. Two teams with identical DORA numbers can have completely different attrition risk. This is what SPACE and DevEx were built to cover, and why most serious measurement programmes now pair delivery metrics with developer experience surveys.

Code quality. Change failure rate is a proxy for one dimension of quality: whether changes break production. It says nothing about maintainability, test coverage, or the technical debt you're accumulating in exchange for speed.

Why is AI making DORA harder to read?

Because throughput and stability used to move together, and now they don't.

The historical DORA finding — the one that made the research famous — was that high performers were fast and stable, which contradicted the assumption that you trade one for the other. AI adoption is separating them again. DORA's own 2025 research found that increased AI adoption correlates with increased delivery instability even while individual effectiveness improves. Analysis of the 2024 data put numbers on it: a 25% increase in AI adoption tracked with a 1.5% drop in throughput and a 7.2% drop in stability.

The 2025 report frames AI as an amplifier rather than a solution — it accelerates teams with solid foundations and magnifies the dysfunction of teams without them. That report drew on nearly 5,000 survey responses and over 100 hours of qualitative data, and it also replaced the familiar four-tier performance ranking with seven team archetypes, on the grounds that a single ladder no longer described what teams were doing.

The practical consequence for anyone reading a dashboard: a change failure rate that rose after your team adopted AI coding tools is not automatically a signal that your team got worse. It's a predictable pattern, and the useful question is where the downstream bottleneck is — usually review, testing, or QA capacity that was sized for a slower rate of incoming change.

How should you use them without causing damage?

Four rules that hold up in practice:

Measure at the service or team level, never the individual. If someone asks for a per-developer breakdown, that request is the problem, not the missing feature.

Pair them with something qualitative. Delivery metrics plus a developer experience survey gives you the "what" and the "why". Delivery metrics alone give you a number and an argument.

Treat them as a diagnostic, not a target. The moment a DORA metric becomes a goal in a performance review, it stops measuring anything. Deployment frequency in particular is trivial to game.

Re-baseline after any major workflow change. Adopting AI assistants, changing your review process, or splitting a monolith all invalidate your previous baseline. Comparing across that boundary produces confident nonsense.

Frequently asked

Are there four DORA metrics or five? Five as of the 2024 report, which added rework rate. Reliability exists alongside them as a quasi-metric introduced in 2021. Guides listing four are describing the pre-2024 framework.

Is MTTR still a DORA metric? It's now called failed deployment recovery time. The rename was deliberate: the metric covers recovery from a failed deployment, not from any incident, and the old name encouraged people to measure the wrong thing.

Can DORA metrics measure AI ROI? Not on their own. They work on pipeline metadata, so they can show that instability rose after AI adoption, but they cannot attribute that change to AI-generated code specifically. That requires reading the diff, which is a different class of tooling.

Do I need a platform to track DORA? No. Deployment frequency and lead time can be derived from your CI system and git history. A platform becomes worth paying for when you need historical trends, segmentation across many teams, or the survey layer.

---