What are DORA metrics? The four keys, explained properly

If engineering has one set of numbers that survived contact with both academia and the boardroom, it's these four. They come from the DORA research program — years of surveying tens of thousands of professionals, popularized by the book Accelerate — and they remain the closest thing the industry has to a standardized benchmark of delivery performance.

This guide explains what each key actually measures, the commonly cited performance bands, how the metrics interact, and the practical mistakes that make DORA programs fail.

The four keys

1. Deployment frequency

How often does your organization successfully release to production?

Frequency is a proxy for batch size. Teams that deploy multiple times a day are shipping small changes — small blast radius, fast feedback, cheap rollbacks. Teams that deploy quarterly are shipping big-bang releases where everything is coupled to everything and any failure is an event.

2. Lead time for changes

How long does it take a commit to reach production?

This clock starts at commit and ends at deploy — it measures your pipeline: review, CI, approvals, release process. It is not the same as customer lead time, which starts when work is requested (we unpack that distinction in cycle time vs lead time). Long lead time for changes almost always points at review queues and release ceremony rather than coding speed.

3. Change failure rate

Change failure rate = deployments causing a failure ÷ total deployments

What share of production changes require a hotfix, rollback, or patch?

This is the stability counterweight to the two speed keys. Any team can deploy hourly if breakage is free; change failure rate makes breakage visible. The definitional discipline matters: agree once on what counts as a "failure" (rollback? hotfix within 24h? incident ticket?) and never renegotiate it mid-quarter.

4. Time to restore service

When a change breaks production, how long until service is restored?

Also known as MTTR. The research insight behind it: failures are inevitable, so elite teams optimize for recovery rather than for the illusion of zero failures. Fast restore times are what make high deployment frequency safe — they turn incidents from crises into routine.

Why speed and stability are measured together

The four keys are designed as a self-balancing system. Push deployment frequency by cutting review corners, and change failure rate rises. Chase a perfect failure rate by adding approval gates, and lead time for changes balloons. You cannot game one key without another testifying against you — which is precisely what makes the set trustworthy as an executive-level scorecard.

The research finding that made DORA famous is that the trade-off most organizations assume — "we can be fast or careful, not both" — is empirically false. Elite performers dominate on all four keys simultaneously, because the same practices (small batches, automated pipelines, fast review, good observability) drive all of them.

Four ways DORA programs fail

• Using the keys to compare teams. A firmware team and a web team have different deployment physics. DORA is a trend instrument per team, and a conversation starter across them — not a leaderboard. The moment a key becomes a target with consequences, Goodhart's law kicks in and the number detaches from reality.
• Measuring only the speed keys. Deployment frequency dashboards without change failure rate are an invitation to ship garbage quickly. Always present speed and stability together.
• Hand-rolled measurement that rots. The classic arc: an engineer scripts the GitLab API into a spreadsheet, the definitions drift, the script breaks, leadership stops trusting the numbers. Continuous, consistently-defined measurement is the difference between a DORA program and a DORA demo.
• Treating DORA as the whole picture. The four keys describe the delivery pipeline. They say nothing about whether you built the right thing, what it cost, or whether the team is burning out — which is why frameworks like SPACE exist, and why pipeline metrics belong next to roadmap flow and cost visibility in one report.

Measuring DORA metrics from GitLab, automatically

Everything needed to compute the four keys already exists in your GitLab metadata: pipelines, deployments, environments, merge requests, and commit timestamps. TheMetrics reads that metadata with read-only access and computes all four keys continuously — benchmarked against the elite/high/medium/low bands, trended over time, and drillable down to the pipelines behind any movement.

The full setup — connect, backfill, dashboard — takes about 20 minutes. Details on the GitLab DORA metrics page; definitions for every metric mentioned here live in the engineering metrics glossary.