How do you know if your software delivery is actually good? Teams argue about it endlessly — some point to how fast they ship, others to how stable things are, and the debate rarely resolves because everyone's measuring different things, or nothing at all. DORA metrics cut through that noise. They're four research-backed measures of software delivery performance, developed through the DORA (DevOps Research and Assessment) program — years of rigorous study into what actually distinguishes high-performing software teams. Rather than arguing about whether your delivery is good, DORA metrics let you measure it objectively, benchmark against others, and improve based on data. They've become the industry standard for measuring DevOps and delivery success precisely because they capture what matters — and understanding them is essential for any organization serious about improving how it builds and ships software.
This guide explains what DORA metrics are, the four measures, what they reveal, why they matter, and how to use them to improve.
What DORA Metrics Actually Are
DORA metrics are four key measures of software delivery performance, established through the DORA research program — a long-running, data-driven study of what makes software teams effective. As the DORA research describes, these metrics emerged from analyzing the practices and performance of thousands of teams, and they distinguish delivery performance in a way that correlates with real outcomes. They've become the widely accepted standard for measuring how well an organization delivers software.
The insight behind them is that good software delivery requires balancing two things that might seem to be in tension: speed (delivering quickly) and stability (delivering reliably). DORA metrics capture both — two metrics for throughput (speed) and two for stability — so that measuring delivery performance means measuring both dimensions together, not sacrificing one for the other. This is what makes DORA metrics powerful: they resist the trap of optimizing only for speed (and breaking things) or only for stability (and moving glacially), measuring instead the balanced performance that actually characterizes elite teams. They provide an objective, research-grounded answer to "how good is our delivery?" — replacing opinion with data.
The Four DORA Metrics
1. Deployment Frequency
How often an organization deploys code to production. It measures throughput — how frequently you're able to ship. Higher-performing teams deploy more frequently, often many times a day, because they've built the automation and practices that make frequent, small deployments safe and routine. Low deployment frequency often signals a slow, risky, manual release process.
2. Lead Time for Changes
The time it takes to get a change from committed code to running in production. It measures how quickly work flows through your delivery process — the speed from "done coding" to "live for users." Shorter lead times indicate an efficient, automated pipeline; long lead times reveal bottlenecks, manual steps, and friction between writing code and shipping it.
3. Change Failure Rate
The percentage of deployments that cause a failure in production — requiring a fix, rollback, or remediation. It measures stability: how often your changes break things. A lower change failure rate indicates higher quality and more reliable delivery, while a high rate signals that changes are too risky and quality controls are insufficient.
4. Mean Time to Restore (MTTR)
How long it takes to recover when a failure does occur in production. It measures stability from the recovery angle — because failures are inevitable, what matters is how quickly you restore service. A short time to restore indicates strong incident response and resilient systems; a long one means failures cause extended disruption.
(More recently, a fifth metric — reliability, reflecting how well services meet their operational goals — has been added to round out the picture, but the four above are the core.)
What They Reveal: Throughput and Stability
The genius of the four metrics is how they pair up. Deployment frequency and lead time measure throughput — how fast and how often you deliver. Change failure rate and time to restore measure stability — how reliably you deliver and how quickly you recover when things break. Together, they reveal the balance that defines delivery performance.
The crucial insight from the DORA research is that throughput and stability are not a trade-off — the best teams excel at both simultaneously. It's a common assumption that moving faster means breaking more things, or that stability requires moving slowly, but the research found the opposite: elite performers deploy frequently and with low failure rates, ship quickly and recover fast. They achieve this through automation, quality practices, and sound engineering that make speed and stability reinforce rather than oppose each other. This is why measuring all four matters — looking at only speed or only stability gives a misleading picture, while the four together reveal whether you're genuinely performing well or excelling at one dimension while failing another.
Why DORA Metrics Matter
The value of DORA metrics comes down to several things. Objective measurement — they replace endless debate about whether delivery is good with data, giving a clear, research-grounded answer. Benchmarking — the DORA research categorizes teams into performance levels (from elite down to low performers) based on these metrics, so you can see where you stand relative to others and what "good" looks like. Correlation with outcomes — critically, the research found that software delivery performance, as measured by these metrics, correlates with broader organizational performance, so improving them isn't just a technical exercise but connects to business results. And data-driven improvement — by measuring these metrics, you can identify where you're weak and focus improvement efforts there, rather than guessing. For organizations investing in DevOps and delivery — building on the automated pipelines covered in this guide to what a DevOps pipeline includes — DORA metrics provide the way to know whether that investment is actually improving delivery, and where to focus next.
How to Improve DORA Metrics
Improving the metrics comes down to the practices that make speed and stability reinforce each other. For throughput (deployment frequency and lead time): automate the build-test-deploy pipeline, make changes smaller and more frequent (smaller changes are faster and safer), and remove manual bottlenecks — the automation at the heart of modern AWS and Azure DevOps practices. For stability (change failure rate and time to restore): invest in automated testing and quality controls to catch problems before production, strong monitoring to detect issues fast, and the ability to roll back or recover quickly when failures occur — the ongoing operational discipline covered in this guide to DevOps support. The through-line is that automation and quality practices improve both throughput and stability together, which is exactly how elite teams achieve both. Improving DORA metrics isn't about pushing one number at the expense of others; it's about building the engineering practices that lift all four.
A Warning: Measure to Improve, Not to Game
One important caution: DORA metrics are meant to drive improvement, not to be gamed. Because they're measurable, there's a temptation to optimize the numbers directly — deploying trivial changes to inflate deployment frequency, or manipulating how failures are counted. This defeats the purpose. The metrics are valuable because they reflect genuine delivery performance that correlates with outcomes, so gaming them produces better-looking numbers and no real improvement. The right use is to measure them honestly, understand what they reveal about your delivery, and improve the underlying practices — letting better metrics follow from genuinely better delivery. Treated as a mirror for improvement rather than a target to hit, DORA metrics are genuinely useful; treated as numbers to maximize, they become meaningless. This is a specific instance of a general truth about metrics: they serve you when they inform improvement, and mislead you when they become the goal.
DORA vs Vanity Metrics
Part of what makes DORA metrics valuable is what they don't measure. Many organizations track vanity metrics — lines of code written, number of commits, hours worked — that feel like productivity but don't correlate with actually delivering value well. DORA metrics focus instead on delivery performance — how effectively you get quality changes to users — which research shows connects to real outcomes. This focus on meaningful, outcome-correlated measurement rather than activity-for-its-own-sake is a large part of why DORA metrics became the standard. They measure what matters about delivery, not what's merely easy to count.
Getting Started
Start measuring the four metrics. Begin tracking deployment frequency, lead time, change failure rate, and time to restore — you can't improve what you don't measure, and establishing the baseline is the first step.
Benchmark honestly. See where you stand relative to the performance levels the DORA research describes, to understand your gaps and what "good" looks like.
Focus improvement on your weakest area. Use the metrics to identify where you're weakest — throughput or stability — and target improvement there, rather than guessing.
Improve the underlying practices. Build the automation, testing, monitoring, and recovery capabilities that lift the metrics genuinely — with experienced DevOps consulting and ongoing support guidance to improve real delivery performance rather than just the numbers.
FAQs
Q1. What are DORA metrics?
DORA metrics are four key measures of software delivery performance, developed through the DORA (DevOps Research and Assessment) research program: deployment frequency, lead time for changes, change failure rate, and mean time to restore. They measure both the throughput (speed) and stability (reliability) of software delivery, providing an objective, research-grounded way to assess how well an organization delivers software.
Q2. What are the four DORA metrics?
They are deployment frequency (how often you deploy to production), lead time for changes (how long from committed code to production), change failure rate (the percentage of deployments causing failures), and mean time to restore (how quickly you recover from failures). The first two measure throughput or speed; the last two measure stability. A fifth, reliability, has more recently been added.
Q3. Why do DORA metrics matter?
Because they replace endless debate about whether delivery is good with objective, research-backed measurement, let you benchmark against performance levels from elite to low, and — crucially — correlate with broader organizational performance, so improving them connects to business outcomes. They also enable data-driven improvement by revealing where you're weak, rather than guessing where to focus.
Q4. Are speed and stability a trade-off in software delivery?
No — this is a key finding of the DORA research. It's commonly assumed that moving faster means breaking more things, but the research found the opposite: elite performers deploy frequently and with low failure rates, shipping quickly while recovering fast. They achieve both through automation and quality practices that make speed and stability reinforce each other rather than oppose.
Q5. How do you improve DORA metrics?
Improve throughput by automating the delivery pipeline, making changes smaller and more frequent, and removing manual bottlenecks. Improve stability through automated testing and quality controls, strong monitoring, and fast rollback or recovery. Automation and quality practices lift both throughput and stability together. Importantly, measure the metrics to drive genuine improvement rather than gaming the numbers, which produces no real benefit.
Final Thoughts
DORA metrics turn "how good is our software delivery?" from an argument into a measurement — four research-backed measures capturing both the speed and the stability that define delivery performance. Their key insight is that throughput and stability aren't a trade-off but reinforce each other in the best teams, achieved through automation and quality practices that lift all four metrics together. Used honestly — to benchmark, identify weaknesses, and improve the underlying practices rather than to game the numbers — they connect technical delivery to real business outcomes and give organizations a clear, data-driven path to shipping better software. Measure the four, focus on your weakest area, and improve the practices beneath them, and delivery performance becomes something you can genuinely see and steadily improve.
Want to measure and improve how your teams deliver software? Book a free consultation with ATH Infosystems' DevOps experts today.