DORA metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery — are the gold standard for measuring software delivery performance. Backed by years of research from the DevOps Research and Assessment team, these four metrics give engineering managers a data-driven view of how well their teams deliver software. This guide shows you how to implement and use them effectively.
What Are DORA Metrics
DORA metrics emerged from the State of DevOps research programme, which has studied thousands of engineering organisations since 2014. The research identified four key metrics that reliably predict software delivery performance and organisational outcomes. Unlike vanity metrics such as lines of code or story points, DORA metrics measure what actually matters: how quickly and reliably teams deliver value to users.
The four metrics work as a balanced set. Deployment Frequency and Lead Time for Changes measure velocity — how fast you can get changes into production. Change Failure Rate and Mean Time to Recovery measure stability — how reliably your deployments work and how quickly you recover when they do not. The research consistently shows that elite teams excel at both velocity and stability simultaneously, debunking the myth that you must sacrifice one for the other.
For engineering managers, DORA metrics provide an objective basis for improvement conversations. Instead of debating whether the team is 'moving fast enough' or 'being careful enough,' you can look at concrete data and set measurable improvement targets.
- Deployment Frequency — how often your team deploys code to production
- Lead Time for Changes — the time from code commit to running in production
- Change Failure Rate — the percentage of deployments that cause failures requiring remediation
- Mean Time to Recovery (MTTR) — how long it takes to restore service after a failure
Implementing DORA Metrics in Your Team
Begin by establishing a baseline for each metric. Most teams can pull deployment frequency and lead time data from their CI/CD pipeline and version control system. Change failure rate requires a clear definition of what constitutes a failure — typically any deployment that results in a rollback, a hotfix, or degraded service. MTTR can be derived from your incident management system.
Automate the collection of DORA metrics wherever possible. Manual tracking is error-prone and unsustainable. Tools like LinearB, Sleuth, Faros, and the open-source Four Keys project can integrate with your existing toolchain to calculate DORA metrics automatically. If you cannot automate immediately, start with a simple spreadsheet and manual updates — imperfect data is better than no data.
Set realistic improvement targets based on the DORA benchmarks. The research classifies teams as Elite, High, Medium, or Low performers. Most teams start in the Medium or Low categories and should aim to move up one level per year. Trying to jump from Low to Elite in a single quarter is unrealistic and will lead to frustration.
Interpreting DORA Metrics Effectively
Always look at DORA metrics as a set, never in isolation. A team that deploys ten times a day but has a fifty percent change failure rate is not performing well — they are just creating chaos faster. Similarly, a team with zero change failures but quarterly deployments is likely so risk-averse that they are not delivering enough value. The goal is to improve all four metrics together.
Context matters when interpreting the numbers. A team maintaining a legacy monolith will have very different DORA metrics from a team building greenfield microservices. Compare your team's metrics against its own historical performance rather than against industry benchmarks or other teams within your organisation. The trend matters more than the absolute number.
Be cautious about using DORA metrics to compare teams against each other or to evaluate individual performance. The metrics are designed to guide improvement at the team and organisational level. Using them as a performance evaluation tool creates perverse incentives — teams will game the metrics rather than genuinely improve their delivery capability.
Common Pitfalls When Using DORA Metrics
The biggest risk with DORA metrics is Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. If you incentivise deployment frequency directly, teams may start making trivially small deployments to inflate the number. If you penalise change failure rate, teams may stop reporting failures honestly. Focus on the underlying capabilities that improve the metrics, not on the numbers themselves.
Another pitfall is neglecting the cultural and organisational factors that DORA metrics depend on. The research shows that technical practices like continuous integration, trunk-based development, and automated testing are necessary but not sufficient. Organisational culture — psychological safety, learning from failures, cross-functional collaboration — is equally important. Improving DORA metrics sustainably requires investment in both technical practices and team culture.
Finally, avoid treating DORA metrics as the only measure of engineering effectiveness. They measure software delivery performance specifically, not broader outcomes like user satisfaction, business impact, or developer experience. Use DORA metrics as part of a balanced measurement approach that includes product metrics, team health indicators, and qualitative feedback.
Building a DORA Metrics Maturity Programme
A mature DORA metrics programme evolves through three stages. In the first stage, you establish baseline measurements and build awareness. The goal is not immediate improvement but understanding where you are and creating a shared vocabulary for discussing delivery performance.
In the second stage, you identify specific bottlenecks and invest in targeted improvements. If your lead time is high, investigate where time is spent in the delivery pipeline — is it code review latency, test execution time, or deployment queue waiting? Each bottleneck requires a different intervention, and DORA metrics help you focus on the right one.
In the third stage, DORA metrics become part of your team's operating rhythm. You review them regularly, set quarterly improvement targets, and use them to guide investment decisions. At this stage, the metrics inform rather than drive your strategy — they are one input among many that help you make better decisions about where to invest engineering effort.
Key Takeaways
- DORA metrics measure what matters: velocity and stability of software delivery
- Elite teams excel at both speed and stability — you do not have to choose between them
- Automate metric collection and compare against your own historical performance, not other teams
- Focus on improving underlying capabilities rather than gaming the numbers
- Use DORA metrics as part of a balanced measurement approach, not the sole indicator of success
Frequently Asked Questions
- What are the benchmarks for elite DORA metrics performance?
- According to the most recent State of DevOps report, elite performers deploy on demand (multiple times per day), have a lead time for changes of less than one hour, a change failure rate of zero to fifteen percent, and recover from failures in less than one hour. High performers deploy between once per day and once per week, with lead time of one day to one week, change failure rate of sixteen to thirty percent, and recovery time of less than one day. These benchmarks provide useful targets but should be adapted to your specific context.
- How long does it take to see improvement in DORA metrics?
- Most teams see measurable improvement within three to six months of focused effort. However, the timeline depends heavily on your starting point and the nature of the improvements needed. Technical changes like implementing continuous integration or automated testing can yield results relatively quickly. Cultural changes like building psychological safety or shifting to a learning-from-failure mindset take longer — often twelve to eighteen months for meaningful, sustained improvement.
- Can DORA metrics be applied to non-web applications?
- Yes, though the specific definitions may need adaptation. For embedded systems, mobile applications, or on-premises software, 'deployment to production' might mean a release to an app store, a firmware update, or a customer-facing release. The underlying principles — measuring how quickly and reliably you deliver value — apply regardless of the delivery mechanism. Adjust the metric definitions to fit your context while preserving their intent.
Try the Engineering Metrics Calculator
Use our interactive tools to benchmark your team's DORA metrics performance and identify specific areas for improvement in your software delivery pipeline.
Learn More