What are DORA metrics, and what they can't tell you

DORA metrics measure two things about an engineering team: how fast code gets to production, and how often it breaks on the way. They come from Google’s DevOps Research and Assessment team, and they’re the industry standard for judging whether a delivery process is healthy.

Here’s what they don’t do: tell you what shipped. DORA doesn’t look at what a change contains. A deploy counts the same whether it’s the payments feature your biggest customer is waiting on or a typo fix in a README. If you’re a founder, PM or exec reading the dashboard to see whether the roadmap moved, that gap is the whole problem.

The DORA metrics, defined

There are five now, not the four most articles still cite. Using DORA’s own definitions:

• Change lead time: how long a change takes to get from commit to production.
• Deployment frequency: how often you deploy.
• Failed deployment recovery time: how fast you recover when a deploy fails.
• Change fail rate: what share of deploys need a rollback or hotfix.
• Deployment rework rate: what share of deploys were unplanned, forced by a production incident.

The first three measure speed. The last two measure stability. All five describe the pipeline. None of them describe the work.

What DORA metrics can’t tell you

They measure the pipe, not what goes through it

The metrics count deploys and time them. That’s it. There’s no way to say “customers can now pay by invoice” in numbers like these.

So a week of dependency bumps and test fixes charts exactly like the week you shipped the feature that closed the enterprise deal. Same bars, very different quarters.

Deployment frequency answers “is the machine running smoothly?” Your investor is asking “did we build the thing?”

Good numbers don’t mean the roadmap moved

A team can improve all five metrics for a year while the product goes nowhere. Small changes, shipped often, recovering fast, none of them touching what the business needs.

The reverse is also true. Six weeks on one hard migration looks terrible on a DORA chart. It might be the most valuable thing the company shipped all year.

They were built for teams, not for stakeholders

DORA says this itself. Its guidance warns against “setting metrics as a goal,” because doing so “increases the likelihood that teams will try to game the metrics.” It also says not to compare the numbers across different teams and apps, because the comparison misleads.

That’s the fine print most dashboards skip. These are self-improvement tools for the team. The moment they go up the chain as a report card, they get gamed and they get misread.

The question DORA was never designed to answer

The “what shipped” answer isn’t missing. It’s sitting in your commit history, in full detail. It’s just written in a language stakeholders don’t read: diffs, branch names, and messages like fix race in webhook handler (again).

DORA reads that history and keeps only the timestamps. Great for tuning a process. Useless for “what did the team ship this month?”

So most companies bridge the gap with a person. A CTO or EM digs through merged PRs, strips the jargon, and writes the update by hand. It works. It also costs half a day of your most expensive engineer, every time.

Common questions

Are there four DORA metrics or five?

Five, in DORA’s current guidance. Deployment rework rate joined the original four. Most tools and posts still say four, so expect both numbers in the wild.

Do DORA metrics measure developer productivity?

No, and the researchers behind them say so. The SPACE framework, from Nicole Forsgren and colleagues, argues productivity “cannot be measured by a single metric or dimension.” DORA covers delivery speed and stability. That’s one dimension of several.

Run both, for different audiences

Keep the DORA dashboard for the engineers who can act on it. For everyone asking what got built, add the other half: a summary of the work itself, on a schedule, pulled from the same repository.

That’s the half DevSummary produces. It reads your GitHub organization’s commits and turns them into a report a founder can forward to the board without editing.

Your delivery metrics tell you the pipeline is healthy. They will never tell you the roadmap moved.