DORA metrics explained: deployment frequency, lead time, change failure rate and time to restore service, and how to use them well.
Measuring software teams by lines of code or tickets closed rarely helps. The DORA (DevOps Research and Assessment) programme identified a small set of metrics that describe software delivery performance in a balanced way.
The core metrics
- Deployment frequency: how often changes reach production.
- Lead time for changes: how long it takes a committed change to reach production.
- Change failure rate: the share of deployments that cause a failure needing remediation.
- Time to restore service: how quickly service is restored after a failure.
The first two describe throughput; the last two describe stability. DORA’s research has found that high-performing teams tend to do well on both, rather than trading one for the other. More recent DORA reports have also explored reliability and rework.
How to use them well
- Measure at team or service level, and focus on trends over time.
- Use metrics to find bottlenecks — slow reviews, manual testing, risky releases.
- Never use them to rank individuals or compare unrelated teams.
- Combine them with developer experience feedback.
Practices that improve them
Small batch sizes, trunk-based development, automated testing, continuous delivery pipelines, feature flags and good observability all tend to improve both speed and stability.
Best practices for using DORA metrics well
- Measure automatically. Pull data from version control, CI/CD and incident tools rather than relying on manual reporting.
- Use metrics for learning, not ranking. Comparing teams with different products and constraints creates incentives to game the numbers.
- Look at all four together. Speed metrics without stability metrics can hide risky behaviour, and vice versa.
- Watch trends. Improvement over time matters more than any single benchmark.
- Pair with qualitative insight. Developer surveys and retrospectives explain why metrics change.
Proven ways to improve each metric
- Deployment frequency: smaller batch sizes, trunk-based development and automated pipelines.
- Lead time for changes: faster code review, reliable automated tests and fewer manual approvals.
- Change failure rate: better test coverage, feature flags and progressive delivery such as canary releases.
- Time to restore service: strong observability, clear on-call ownership, rehearsed runbooks and easy rollback.
Beyond the four keys
DORA research also highlights reliability and the capabilities that drive performance, including continuous integration, loosely coupled architecture, documentation quality and a generative culture. Platform engineering and developer experience initiatives often target these capabilities directly.
Common mistakes to avoid
- Setting targets that encourage splitting deployments artificially.
- Ignoring how incidents are recorded, which skews failure metrics.
- Treating the metrics as the goal rather than as indicators of capability.
Frequently asked questions
Do DORA metrics apply to non-software teams?
They were designed for software delivery, though similar flow metrics can help infrastructure and data teams.
How often should we review them?
Monthly reviews by teams, with quarterly trends for leadership, work well for most organisations.
A 90-day action plan
Days 1 to 30: agree definitions for each measure with engineering leaders, connect version control, pipeline and incident tools, and capture a baseline for several teams.
Days 31 to 60: review results with each team, identify the main constraint, such as slow code review or manual testing, and choose one improvement experiment.
Days 61 to 90: measure the effect of each experiment, share lessons across teams and add a short developer survey to capture qualitative insight.
Questions teams should discuss
- Where does work wait the longest between commit and production?
- Which types of change cause most failures, and why?
- How quickly can we detect a problem after release?
- Can we roll back or disable a feature in minutes?
- What would let us release smaller changes more often?
Key terms explained
- Deployment frequency: how often code is released to production.
- Lead time for changes: the time from commit to running in production.
- Change failure rate: the share of releases that cause a failure needing remediation.
- Time to restore: how long it takes to recover from a failure in production.
- Trunk-based development: integrating small changes into the main branch frequently.
The bottom line
Four simple measures give software teams a balanced view of speed and stability. Used for learning rather than ranking, measured automatically and reviewed alongside qualitative feedback, they highlight where to invest in automation, architecture and practices. Focus on trends within each team, run small improvement experiments and share what works. The real goal is better outcomes for users, and the numbers are simply a guide along the way.
Further reading on DORA metrics
For authoritative, vendor-neutral guidance on DORA metrics, see the DORA research programme. You can also browse our free whitepapers.
