DORA Metrics: A Framework for Delivery Performance
- Shawn West
- Jun 14
- 7 min read
Updated: Aug 20
DORA — DevOps Research and Assessment — published a framework of four metrics that predict software delivery performance. The metrics are simple to describe and hard to game. Together, they tell a useful story about whether a team is delivering software well.
This guide is the four metrics, what they mean, and how to use them.
The Four Metrics
Deployment Frequency: how often you deploy to production
Lead Time for Changes: how long from code committed to running in production
Change Failure Rate: what percentage of deploys cause incidents
Mean Time to Recovery (MTTR): how long to recover from an incident
Two metrics about speed; two about quality. The framework's insight: high-performing teams excel at both, not one at the expense of the other.
Why These Four
The DORA research found these four metrics correlate strongly with:
Organizational performance (revenue, market share)
Team well-being (lower burnout, higher job satisfaction)
Software quality (fewer incidents, faster recovery)
The metrics aren't proxies for these outcomes — they predict them.
Deployment Frequency
How often do you deploy to production?
The DORA benchmarks:
Elite: multiple times per day
High: between once per week and once per month
Medium: between once per month and once per six months
Low: less than once per six months
Higher frequency correlates with better outcomes because it forces small batches. Small batches mean each deploy is less risky, easier to test, and easier to roll back.
Teams that deploy rarely tend to:
Batch many changes together (high risk per deploy)
Have long change-detection lead times
Treat each deploy as a special event requiring ceremony
Teams that deploy often have automated their pipeline to the point where deploys are routine.
Lead Time for Changes
From the moment code is committed, how long until it's running in production?
The benchmarks:
Elite: less than one hour
High: between one day and one week
Medium: between one week and one month
Low: more than one month
Short lead times require:
Fast CI/CD pipelines
Automated testing
Low manual gates
Confidence in the deployment process
Long lead times indicate friction — manual approvals, lengthy testing, batched releases.
Change Failure Rate
What percentage of deploys cause incidents, hotfixes, or rollbacks?
The benchmarks:
Elite: 0-15%
High: 16-30%
Medium: 16-30%
Low: 16-30%
(DORA's "Elite" tier is the only one with a low ceiling; Medium and Low can have higher rates.)
Note: change failure rate doesn't have to be very low. Even Elite teams have failures. The key is recovering fast and learning from them.
Mean Time to Recovery
When something breaks, how long until it's fixed?
The benchmarks:
Elite: less than one hour
High: less than one day
Medium: between one day and one week
Low: more than one week
Fast recovery requires:
Good monitoring (you know when something's broken)
Good runbooks (you know what to do)
Easy rollback (you can revert)
Practiced incident response
Slow recovery often means recovery procedures are theoretical rather than practiced.
What the Metrics Tell You Together
The interplay matters as much as individual numbers.
High deployment frequency + low lead time + low failure rate + low MTTR: elite performance. The team has a healthy pipeline and good practices.
High frequency + high failure rate: shipping fast without quality. The pipeline outpaces the testing.
Low frequency + low failure rate: safe but slow. Likely over-batching changes.
High frequency + high MTTR: fast pipeline but no recovery capability. Risky.
The four numbers together diagnose where to invest.
Tracking the Metrics
Measurement is the first challenge. You need:
Deployment events: when did production deploys happen? (from CI/CD)
Commit-to-deploy data: when was each commit deployed? (from git + CI/CD)
Incident records: which deploys caused incidents? (from incident management)
Recovery times: when did incidents start and end? (from incident management)
Tools like LinearB, Sleuth, and Faros aggregate these. For smaller teams, a simple spreadsheet can work.
Interpretation
The metrics are aggregate. Per-deploy variation is huge. Look at trends over weeks/months, not individual data points.
Compare against the team's own history more than against benchmarks. A team improving from "medium" toward "high" is more important than its current ranking.
Common Misuse
As performance management. Using DORA for individual evaluation produces gaming. Engineers split commits, skip difficult changes, avoid risky work.
As inter-team comparison. Different teams have different contexts; comparing them without nuance is misleading.
Gamification. Optimizing for the metric rather than the underlying quality. Frequent deploys of trivial changes don't actually represent throughput.
Single-metric focus. Optimizing one at the expense of others. Improving frequency by shipping broken code makes things worse.
The metrics should drive team conversation, not management surveillance.
Improving Each Metric
To improve Deployment Frequency:
Smaller PRs
Faster CI
Automated testing
Trunk-based development
Reduce manual approvals
To improve Lead Time:
Address pipeline bottlenecks
Reduce manual gates
Automate tests that are running manually
Parallelize what runs serially
To improve Change Failure Rate:
Better automated testing
Pre-merge validation
Feature flags for risky changes
Canary deployments
To improve MTTR:
Monitoring that catches issues fast
Runbooks for common failures
Tested rollback procedures
Practice via game days
Each metric has specific levers. The diagnosis tells you which levers to pull.
The Cultural Side
DORA's research also identified cultural factors that correlate with performance:
Psychological safety
Trust between teams
Learning culture
Generative (not blame-oriented) organization
You can't fix DORA metrics with tooling alone if the culture isn't supportive. Investment in culture pays back in the metrics.
Beyond DORA: SPACE Framework
A separate framework, SPACE — published in ACM Queue in 2021 — measures different ground:
Satisfaction and well-being
Performance (DORA-like)
Activity (volume of work)
Communication and collaboration
Efficiency and flow
SPACE is broader and harder to measure, and it is not a later stage of DORA — the two answer different questions and are meant to sit side by side. For most teams the delivery metrics are the place to start, because they come from data you already emit.
What DORA Doesn't Measure
DORA is silent on:
Whether you're building the right thing
Product quality from a customer perspective
Code maintainability
Team happiness specifically
Architectural soundness
Use DORA alongside other measures, not as a complete picture.
A Working Use of DORA
For an engineering organization:
Measure baseline. Where are you on each metric?
Identify the weakest dimension. Where's the most opportunity?
Invest there. Make changes targeted at that dimension.
Re-measure. Did the investment move the metric?
Repeat with the next weakest dimension.
The iteration produces real progress. Treating DORA as a one-time benchmark misses the value.
Anti-Patterns
DORA dashboards for executives. Without context, the numbers are misleading.
DORA-driven feature work. Optimizing for metric improvement instead of actual value.
DORA as the only metric. Other things matter; DORA doesn't capture them.
DORA without action. Measuring; not improving.
A Worked Example
An engineering team measures:
Deployment Frequency: weekly
Lead Time: 5 days
Change Failure Rate: 20%
MTTR: 4 hours
Their interpretation:
Lead Time and Frequency suggest under-batched changes (slow pipeline?)
20% failure rate is on the edge; investigate root causes
MTTR is reasonable for the scale
Investments:
Reduce CI runtime from 30 min to 10 min
Add automated tests for the most-failed change types
Adopt feature flags for risky changes
After 3 months, they re-measure:
Frequency: 3x per week
Lead Time: 1 day
Change Failure Rate: 12%
MTTR: 2 hours
Real progress. The framework guided investment.
What has changed since these four were named
This article describes the classic four keys, which is still the right starting point. But DORA has revised both the set and the names, and quoting the old ones in a room where someone has read the current report will cost you the argument.
What this article calls it | Current DORA name | What changed |
Mean Time to Recovery (MTTR) | Failed deployment recovery time | Renamed and narrowed in 2023. The old framing could not separate an impairment your change caused from one caused by something external, such as a data-centre outage, which made it inconsistent with the other metrics |
Change Failure Rate | Change fail rate | Same measure, and now grouped with a second instability metric rather than standing alone |
— | Deployment rework rate | Added. Unplanned deployments that follow a production incident — work triggered by a failure, distinct from the emergency fix that change fail rate already counts |
Deployment Frequency, Lead Time | Deployment frequency, change lead time | Unchanged in substance; now grouped as throughput metrics |
The practical consequence for the MTTR section above: scope your recovery clock to impairment caused by a change you deployed. Leave general outages in and you are measuring your cloud provider alongside your team.
Reading the benchmark bands honestly
The bands quoted above come from DORA's State of DevOps reports, and the thresholds have changed between report years. A team that reads as one tier against one year's table can land differently against another. Name the year beside any band you quote, and check the current report rather than a number remembered from a conference talk.
The change failure rate bands are the ones that confuse people, and this article already gestures at why: the top clusters have shared a band in DORA's published tables. That is a real finding rather than a transcription error — change failure rate separates the top clusters least cleanly, which makes it the weakest of the four to rank teams by. It is a good metric for watching your own trend and a poor one for league tables.
Key Takeaway
DORA measures delivery performance through four metrics: Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR. High performance requires improving all four together, not one at the expense of others. Track against your own history more than against benchmarks. Use the metrics to diagnose where to invest; avoid using them for individual performance management. Pair with cultural investment — tooling alone doesn't move the metrics in unhealthy cultures. DORA is one part of the picture; use alongside product and quality measures.
Sources
DORA, DORA's software delivery performance metrics — the current five-metric set, the throughput and instability grouping, and current definitions.
DORA, A history of DORA's software delivery metrics — the 2023 rename of MTTR to failed deployment recovery time and the reasoning behind narrowing it.
DORA, Research — the State of DevOps report archive, 2014 onward. Band thresholds live inside the individual annual reports and differ by year.
Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler, The SPACE of Developer Productivity, ACM Queue vol. 19, no. 1 (February 2021) — the SPACE framework. Note it is not an extension of DORA: it is separate work from Microsoft Research, GitHub and the University of Victoria, and Nicole Forsgren co-authoring both is where the assumed lineage comes from.
Further reading on this site: References & Sources.
Related reading
Keep learning. This article is part of the Advanced Quality Engineering path in the ShiftQuality Learning Center. Take quality from a team chore to an organizational property.
