Quick Summary
DORA metrics help engineering teams measure software delivery outcomes rather than activity. By tracking deployment frequency, change lead time, change failure rate, failed-deployment recovery time, and deployment rework rate, teams can assess whether they are delivering software quickly, reliably, and with less disruption.
The real value comes from using these metrics to guide continuous improvement. DORA metrics reveal issues such as pipeline bottlenecks, excessive rework, weak testing, and slow incident recovery, allowing teams to make targeted changes and measure their impact. With consistent baselines and measurement, engineering teams can replace intuition with evidence, ultimately shipping software faster with greater confidence and reliability.
Introduction
Most engineering teams have plenty of data about their work. Sprint velocity. Story points completed. Bug counts. Lines of code committed. These numbers are easy to generate and easy to report. They appear on dashboards, in weekly standups, and in quarterly reviews. They create the impression that the team’s performance is being measured and understood.
The problem is that none of them tell you whether the team is actually getting better at delivering software. Velocity measures how much work moves through a process. It says nothing about whether that work is reaching users reliably, quickly, or without breaking things along the way. A team can have excellent velocity and consistently slow, unreliable delivery. The metrics look healthy, while actual delivery performance remains flat or worsens.
This is the gap that DORA metrics were designed to fill. Not as a replacement for existing engineering metrics, but as a different kind of signal- one that measures delivery outcomes rather than delivery activity, and that connects engineering work to the things that actually matter for users and the business.
What DORA Metrics Actually Measure
The DORA framework emerged from years of research by the DevOps Research and Assessment program, which studied thousands of engineering teams across industries to understand what actually predicts software delivery performance. The research found that five specific metrics consistently separated high-performing teams from lower-performing ones, not team size, technology choices, or budget, but specific behaviors around how teams deployed software and responded when things went wrong.
These five DORA metrics are now the standard framework for measuring software delivery performance.
1. Deployment Frequency
Deployment frequency measures how often a team releases code to production. This metric captures the team’s ability to deliver value continuously rather than in large, infrequent batches. Teams that deploy frequently tend to ship smaller changes, which are easier to test, easier to understand, and easier to roll back when something goes wrong. The DORA research consistently finds that more frequent deployment correlates with higher reliability rather than lower, counterintuitive but mechanically sound.
2. Lead Time for Changes
Lead time for changes measures how long it takes from when a developer commits code to when that code runs in production. This is the engineering organization’s cycle time, the speed at which work moves from completion to delivery. Long lead times usually indicate friction in the pipeline rather than slow development. Code waiting for review, environments unavailable for testing, approval gates that introduce delays- these are the factors that inflate lead time, and they are all addressable once they are visible.
3. Change Failure Rate
Change failure rate measures the percentage of deployments that cause a problem requiring remediation- a rollback, a hotfix, or a production incident. This is the quality signal in the DORA framework. A low change failure rate indicates that the team’s validation and testing practices catch problems before they reach users. A high change failure rate means problems consistently reach production, creating rework, eroding user trust, and consuming engineering time that could be spent building new features.
4. Failed Deployment Recovery Time
Failed deployment recovery time measures how long it takes to restore normal service after a production incident. This metric captures organizational resilience- how quickly the team can detect, diagnose, and resolve problems when they occur. Teams with short recovery times have invested in observability, practiced their incident response processes, and built deployment architectures that support fast rollback. Teams with long recovery times have gaps in one or more of these areas, which prove costly whenever an incident occurs.
5. Deployment Rework Rate
Deployment rework rate, the fifth metric added to the DORA framework in 2024, measures the proportion of deployment effort spent fixing previously shipped work. It captures the rework burden- how much of the team’s capacity is going toward addressing failures in what was already deployed rather than toward shipping new value. A high deployment rework rate, alongside a low change failure rate, often signals that the definition of change failure rate omits failures that surface after the immediate post-deployment window.
Why Teams That Track These Metrics Improve Faster
The connection between tracking DORA metrics and shipping better software faster is not automatic. Tracking metrics does not improve them; understanding what they are telling you and acting on that information does. But the teams that track DORA metrics consistently improve faster than teams that do not, for a specific reason: these metrics point to the right problems.
Most engineering performance discussions focus on inputs. How many engineers do we have? Are they productive? Are they working on the right things? These are legitimate questions, but they are hard to connect to outcomes. Adding engineers does not automatically make delivery faster or more reliable. Having engineers work harder does not reduce the change failure rate. The input-focused view of engineering performance generates activity without necessarily generating improvement.
DORA metrics focus on outputs. How fast is working software reaching users? How often does it break when it gets there? How quickly can the team recover when it does? These questions connect directly to what users and the business actually care about, and they point to specific, addressable problems when the answers are not where the team wants them to be.
A high change failure rate points to the validation and testing infrastructure. Something in the process of checking whether code is ready to ship is not catching failures that reach production. Addressing this might mean improving integration test coverage, validating service behavior against current dependency behavior rather than outdated mock files, or implementing staged deployment strategies that catch issues before full traffic exposure.
For API-driven systems specifically, one of the most common sources of elevated change failure rate is mock files that have drifted from the current behavior of the services they represent. The team addresses this by capturing real HTTP traffic between services and generating test cases and dependency mocks from those actual interactions rather than from manually maintained specifications.
When downstream services change their behavior after a deployment, new traffic captures automatically reflect those changes, keeping pre-deployment validation accurate without requiring manual mock maintenance. The result is that the change failure rate reflects actual deployment quality rather than pipeline performance, which is based on outdated assumptions.
A long lead time points to pipeline friction rather than development speed. The fix is in identifying where code accumulates waiting time – review queues, environment availability, approval processes – and addressing those specific bottlenecks rather than asking developers to work faster.
A low deployment frequency combined with long lead time points to batch size and coordination overhead. The fix is to break work into smaller units that can move through the pipeline and reach production independently, rather than waiting for a coordinated release event.
The Compounding Effect of Consistent Measurement
One of the less obvious benefits of tracking DORA metrics is the way consistent measurement affects engineering teams’ decision-making over time.
When teams lack clear outcome metrics, improvement efforts are necessarily based on intuition and experience. A senior engineer suspects that the deployment process has too many manual steps and proposes automation. The proposal gets funded, or it does not, based on how persuasively it can be argued rather than on evidence of what the current process is costing. If the automation is implemented, it is difficult to determine whether it actually improved anything because there was no clear baseline to compare against.
When teams track DORA metrics consistently, this dynamic changes. The baseline exists. Proposed improvements can be evaluated against specific metric targets. After implementation, the effect of the change is visible in the metrics rather than in anecdotes about how things feel different. Teams can distinguish between changes that genuinely improved delivery performance and changes that felt productive without moving the numbers.
This evidence-based improvement cycle is what produces the compounding effect that the DORA research has found among high-performing teams. They are not better because they are smarter or better resourced. They are better because they have been measuring the right things long enough to understand what actually drives their specific delivery performance and to act on that understanding consistently.
Starting With DORA Metrics
For teams that are not currently tracking DORA metrics, starting does not require sophisticated tooling or a major process change. The five metrics can be calculated from data that most teams already have: deployment logs, commit timestamps, incident records, and deployment history.
The most useful starting point is to pick whichever metric the team suspects is furthest from where it should be and establish a baseline. Not to fix it immediately, but to understand what it actually is.
Many teams that start tracking change failure rates discover that they are significantly higher than expected. Many who start tracking lead time discover that most of the time is spent waiting rather than actively developing. The measurement itself reveals information that changes how the team thinks about what needs improvement.
From that baseline, the improvement cycle the DORA framework enables begins by identifying the specific friction points revealed by the metrics, making targeted changes, and measuring whether those changes actually moved the numbers. Teams that run this cycle consistently for six months to a year report a specific change in how they approach their delivery process.
Not just faster shipping, but more confident shipping, a clearer understanding of what their pipeline is actually telling them, and more certainty that improvements they make are producing real results rather than just producing activity.
