DevOps delivery value is measured primarily through the four DORA metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service, which together capture both how fast a team ships and how stable that shipping is. The question of how DevOps delivery value is measured comes up constantly because teams sense that "we deploy a lot" and "we deliver value" are not the same claim, and they want a framework that connects the two honestly. The DORA metrics, from the DevOps Research and Assessment program, are the most widely adopted answer, and the key insight behind them is that speed and stability are measured together, not traded off.
This guide explains the four metrics, why a fifth dimension around security matters, and the ways these numbers get gamed or misread.
The four DORA metrics
The framework splits into two throughput metrics and two stability metrics, and looking at only one pair gives you a distorted picture.
Deployment frequency measures how often you successfully release to production. Elite teams deploy on demand, often many times a day; lower-performing teams deploy weekly or monthly. It is a throughput signal: frequent, small deployments correlate with lower risk per change because each change is smaller and easier to reason about.
Lead time for changes measures how long it takes for a commit to reach production. This captures the efficiency of your whole pipeline, from code review through testing to release. Short lead times mean you can respond to a customer need or a security fix quickly; long lead times mean value sits unshipped and risk sits unpatched.
Change failure rate measures the percentage of deployments that cause a failure requiring remediation (a rollback, a hotfix, an incident). This is the counterweight to the throughput metrics. A team can inflate deployment frequency by shipping recklessly, and change failure rate is what catches that.
Time to restore service (sometimes called failed deployment recovery time) measures how long it takes to recover when a failure does occur. Failures are inevitable; what distinguishes strong teams is that they recover in minutes rather than days, because they have good observability, easy rollback, and rehearsed incident response.
The reason all four matter together is that any single metric can be gamed. Optimize deployment frequency alone and you encourage sloppy releases. Optimize change failure rate alone and you encourage shipping nothing. The set is designed so that improving your delivery value genuinely means moving all four in the right direction at once.
Why security belongs in the measurement
The classic four metrics say a lot about speed and stability but nothing directly about whether you are shipping vulnerable software quickly. A team can post elite DORA numbers while accumulating security debt, because a vulnerable dependency that has not caused an incident yet does not show up in change failure rate.
Mature DevSecOps programs extend the measurement to close that gap. Useful security-delivery signals include mean time to remediate vulnerabilities (how long a known issue stays open once discovered), the percentage of deployments that pass automated security gates, and the rate at which new vulnerabilities are introduced versus resolved over time. These sit naturally alongside the DORA metrics because they answer the same shape of question: are we fast and are we stable, now including "are we secure."
The practical move is to measure remediation with the same rigor as delivery. If your lead time for a feature is two days but your lead time for a critical security fix is three weeks, that gap is a delivery-value problem your standard DORA dashboard will not reveal. Instrumenting how quickly a vulnerability flagged by an SCA tool moves from detection to a merged fix gives you the security analogue of lead time, and it is often the more important number.
How to actually collect the numbers
The data mostly already exists in systems you run. Deployment frequency and change failure rate come from your CI/CD system and your incident tracker. Lead time comes from correlating commit timestamps with deployment timestamps, which your version control and pipeline logs contain. Time to restore comes from your incident management tooling.
The engineering effort is in the correlation, not the collection. Getting an accurate lead-time number means reliably linking a specific commit to the specific deployment that carried it to production, which requires consistent tagging or a deployment record that references the commit range. Teams that skip this end up eyeballing the numbers, which defeats the purpose.
Resist the urge to measure everything at once. Start with the four DORA metrics, get them accurate and trusted, and only then layer in security and flow metrics. A dashboard with twenty metrics that nobody trusts is worse than four that the team believes.
The traps that make the numbers lie
Metrics change behavior, and not always the behavior you wanted, so a few traps are worth naming.
Vanity deployment frequency is the most common. If you count every trivial config push as a deployment, your frequency looks elite while your meaningful release cadence has not changed. Define what counts as a deployment and apply it consistently.
Using the metrics to rank individuals or teams against each other reliably backfires. The moment a number becomes a performance-review input, people optimize the number rather than the underlying outcome, and the data stops reflecting reality. DORA metrics are meant to guide a team's own improvement over time, not to be a leaderboard.
Ignoring context comparisons is another. A team maintaining a legacy monolith with a manual compliance sign-off will have a longer lead time than a team on a greenfield service, and that difference is not laziness. Compare a team to its own trend, not to an unrelated team.
And the subtlest trap: treating good DORA numbers as proof of quality or security. They measure delivery performance, which is necessary but not sufficient. You can deliver fast and stable and still ship insecure or low-value software. That is exactly why the security-delivery metrics matter, and why our Academy treats measurement as one input to a program rather than the whole story.
FAQ
What are the four metrics used to measure DevOps delivery value?
Deployment frequency, lead time for changes, change failure rate, and time to restore service, known collectively as the DORA metrics. The first two measure throughput (how fast you ship), the last two measure stability (how reliably you ship), and they are meant to be read together so that speed is never improved at the expense of stability.
How is DevOps delivery value measured beyond speed?
By pairing throughput metrics with stability metrics, and increasingly with security-delivery signals. Change failure rate and time to restore service capture stability, while mean time to remediate vulnerabilities and the percentage of deployments passing security gates capture whether fast delivery is also safe delivery.
Can DORA metrics be gamed?
Yes, which is why all four are used together. Optimizing deployment frequency alone rewards reckless releases; optimizing change failure rate alone rewards shipping nothing. Counting trivial changes as deployments inflates frequency, and using the metrics to rank individuals pushes people to optimize the number instead of the outcome.
Where should security fit into delivery measurement?
Measure remediation with the same rigor as feature delivery. Track how long a known vulnerability stays open from detection to merged fix (the security analogue of lead time) and what fraction of deployments pass automated security gates. A large gap between feature lead time and security-fix lead time is a delivery-value problem the standard DORA dashboard will not show.