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

What DORA metrics are

DORA metrics are four measurements of software delivery performance, drawn from the DevOps Research and Assessment program - a multi-year research effort that surveyed tens of thousands of engineering professionals to find what actually separates high-performing teams from the rest. The finding that made the metrics famous - speed and stability are not opposites; the best teams are fast and stable at the same time.

The four keys divide neatly into two pairs. Two measure how quickly you deliver value, and two measure how reliably you do it. A team that games one pair at the expense of the other is not improving - it is moving the problem. The point of tracking all four together is to make that tradeoff visible so you cannot hide it.

For a compact reference, see our DORA metrics glossary entry. This guide explains each metric, then shows why code review is one of the biggest levers on the whole set.

The four keys, one at a time

Deployment frequency

How often your team successfully releases to production. Elite teams deploy on demand, often many times a day; lower-performing teams ship weekly or monthly. High frequency is a proxy for small batch sizes - you can only deploy many times a day if each change is small. See deployment frequency.

Lead time for changes

How long a change takes to go from committed code to running in production. This is the metric most directly shaped by your review and CI pipeline, because a PR sitting in a review queue is lead time accumulating with nothing happening. See lead time for changes.

Change failure rate

The percentage of deployments that cause a failure in production requiring a hotfix, rollback, or patch. It measures the quality of what you ship, not the quantity. See change failure rate.

Time to restore service

When something does break, how long until service is healthy again. Elite teams recover in under an hour, which usually reflects small deployments (easy to pinpoint and revert) and good observability. See mean time to recovery.

Metric	Measures	Pair
Deployment frequency	How often you ship	Speed / throughput
Lead time for changes	Commit to production	Speed / throughput
Change failure rate	Share of bad deploys	Stability
Time to restore service	Recovery speed	Stability

The takeaway - read the four together; a gain in one that quietly damages another is not progress.

Why code review is a primary lever

Here is the connection most DORA write-ups skate past. When you decompose lead time for changes, the coding portion is often small. The waiting portion - PR sitting idle, waiting for a first review, waiting for a re-review after changes, waiting to clear the merge queue - frequently dominates. That waiting is review latency, and it is squarely within your control.

Review affects the stability pair too. Shallow, rushed review lets defects reach production, which drives up change failure rate. So review speed and review quality push on both halves of DORA at once - and crucially, the same practices improve both:

• Smaller PRs get reviewed faster (lower lead time) and get reviewed more thoroughly, so fewer defects escape (lower change failure rate). See pull request size best practices.
• Automated first-pass review cuts the wait for initial feedback, shrinking review cycle time that feeds straight into lead time.
• A merge queue keeps a high deployment frequency from breaking main, protecting both throughput and stability. See what is a merge queue.

The takeaway - shortening the time a PR waits for review is one of the cheapest ways to improve lead time without touching your build or deploy pipeline. For concrete tactics, see how to reduce code review time.

How to measure DORA metrics

You can compute the four keys from data you already have - deployment events, commit timestamps, incident records - but stitching that together by hand is brittle. Purpose-built platforms pull it from your Git host and CI automatically.

LinearB is built around exactly this. It provides DORA metrics dashboards with industry benchmarks, tracks PR cycle time to pinpoint where changes stall, and its free tier covers up to 8 contributors with core engineering metrics and PR cycle time tracking (source - LinearB tool page). Because it also surfaces PR cycle time and bottleneck identification, you can see whether review latency specifically is what is inflating your lead time, rather than guessing.

Graphite attacks the same problem from the workflow end. Its 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 (source - Graphite tool page). Measuring the metric and improving the underlying workflow are two sides of the same coin.

Common mistakes with DORA metrics

• Turning them into individual KPIs. DORA measures team and system performance. Ranking developers by deployment count invites gaming and destroys collaboration. Keep them team-level.
• Chasing one number. Pushing deployment frequency while change failure rate climbs is not a win - you are shipping faster and breaking more. Move the set together.
• Ignoring context. A team maintaining a regulated banking core will have a different profile than one shipping a marketing site. Compare against your own trend, not a leaderboard.
• Measuring without acting. A dashboard nobody uses to change the workflow is decoration. The point is to find the bottleneck and remove it.

Conclusion

The four DORA metrics - deployment frequency, lead time for changes, change failure rate, and time to restore service - endure because they capture the thing that actually matters - shipping value quickly and reliably at the same time. Their most important lesson is that speed and stability rise together, and one of the biggest shared levers is code review. Shrink PRs, add an automated first pass, protect main with a merge queue, and measure the result with a platform like LinearB so you are optimizing the real bottleneck instead of the one you assume. Track all four, keep them at the team level, and use them to change how you work rather than to grade people.

Further reading

• How to Reduce Code Review Time
• Pull Request Size Best Practices
• What Is a Merge Queue?
• Code Review Best Practices
• DORA Metrics - glossary definition

Further Reading

• Input vs Output vs Reasoning Tokens Cost - LLM Pricing Explained