Measuring success: the DORA metrics
"Are we good at DevOps?" is not a question you can answer by vibes or by counting story points. The DORA research program spent nearly a decade surveying tens of thousands of engineering teams and found four measurements that reliably separate elite performers from the rest — and none of them is "how many tickets did we close." Read this page and you'll know exactly what each metric means, how to compute it, where your team likely sits, and the one way teams reliably wreck these numbers by chasing them instead of the practices behind them.
Think about a school that wants to know if it's actually teaching well, not just keeping kids busy. Counting homework pages assigned tells you nothing. Better questions: how often do students get a real test back (deployment frequency)? How long from finishing a lesson to being tested on it (lead time)? Out of all the tests given, how many results turn out wrong and need a redo (change failure rate)? When a grade is wrong, how fast does the school catch and fix it (time to restore)? A school that tests constantly, grades fast, and rarely gets it wrong is a better school than one that tests once a semester "to be careful" — DORA found the same pattern holds for shipping software.
The four metrics, precisely
DORA — the DevOps Research and Assessment program, founded by Nicole Forsgren, Jez Humble, and Gene Kim, later acquired by Google — ran annual State of DevOps surveys from 2014 onward and published the underlying statistical model in the 2018 book Accelerate. Out of dozens of candidate metrics they tested, four survived rigorous factor analysis as the ones that actually predict organizational and delivery performance. Two measure throughput, two measure stability:
- Deployment frequency — how often the organization successfully releases to production. Measured as a rate (deploys per day, per week), not a raw count, so teams of different sizes are comparable.
- Lead time for changes — the elapsed time from a commit landing on the trunk to that same code running in production. This is the software-delivery half of the pipeline covered in CI/CD pipelines; it deliberately excludes idea-to-commit time, which DORA treats as a separate product-discovery question.
- Change failure rate — the percentage of deployments to production that cause a degraded service and require remediation: a hotfix, a rollback, a patch. Formula: failed deploys ÷ total deploys over a period, expressed as a percentage.
- Time to restore service — commonly called MTTR (mean time to restore), the elapsed time from a production incident being detected to service being restored, whether by a fix, a rollback, or a mitigation. See incident management for how that clock actually gets started and stopped in practice.
Deployment frequency and lead time measure throughput — how fast value moves. Change failure rate and time to restore measure stability — how well the system tolerates that speed. DORA's research treats them as a single four-number scorecard, not four metrics to optimize independently.
The counter-intuitive finding: speed and stability move together
The finding that made Accelerate required reading is this: elite performers do not trade stability for speed. They have both — deploying far more frequently than low performers while simultaneously failing less often and recovering faster. This directly contradicts the intuition that shipping faster must mean breaking more things, an intuition baked into most change-approval processes, which slow deployment down in the name of safety.
The mechanism DORA identifies is architectural and cultural, not a shortcut: small, frequent, reversible changes are individually lower-risk than large, infrequent, batched ones. A single-line config change deployed alone is easy to reason about and easy to roll back; twenty commits from three teams batched into one Friday release is not. Practices like trunk-based development (see version control & branching), automated testing, and deployment strategies that support fast rollback are what let a team increase deploy frequency without increasing risk — the frequency itself isn't the cause of the stability, both are downstream of the same engineering practices. Throughput and stability, in other words, are not opposite ends of a dial you trade off against each other; they're correlated in the same direction because both are effects of the same underlying causes.
The performance tiers and benchmark numbers
DORA buckets survey respondents into four performance clusters — Elite, High, Medium, Low — based on where their answers land across all four metrics together. The bucketing isn't self-reported; it comes from cluster analysis on the underlying survey data. The table below reflects the benchmark ranges that have been consistent across recent State of DevOps reports:
| Tier | Deployment frequency | Lead time for changes | Change failure rate | Time to restore service |
|---|---|---|---|---|
| Elite | On-demand — multiple deploys per day | Less than one hour | 0–15% | Less than one hour |
| High | Between once per week and once per month | One day to one week | 16–30% | Less than one day |
| Medium | Between once per month and once every six months | One month to six months | 16–30% | One day to one week |
| Low | Fewer than once per six months | More than six months | 16–30% | More than six months |
Two things worth noticing. First, the gap between Elite and Low deployment frequency isn't incremental — it spans multiple deploys a day versus fewer than two a year, several orders of magnitude apart. Second, change failure rate bands have converged in recent reports across High, Medium, and Low tiers (all landing in the same 16–30% range), with Elite the clear outlier at 0–15%; the tier separation in recent years is driven mainly by throughput and restore speed, not by failure rate alone. Use these numbers as a rough compass for where your team sits, not a certification exam — DORA itself cautions that the survey methodology and exact cutoffs shift slightly year to year.
Measuring these without gaming them
All four metrics are computable from data most teams already have: deployment frequency and lead time come from your CI/CD system's deploy logs and commit timestamps (tools like GitHub Actions, GitLab CI, or Jenkins can export this directly); change failure rate and time to restore require tagging which deployments caused an incident, which usually means linking your deploy log to whatever your team uses for incident management — a PagerDuty or Opsgenie timeline, or a manually logged incident register. The DevOps toolchain page covers specific tools that automate this correlation, such as Sleuth, LinearB, and Google's own DORA Metrics tooling built on GitHub/GitLab APIs.
Goodhart's Law — "when a measure becomes a target, it ceases to be a good measure" — applies directly here. A team told to raise deployment frequency can hit the number without improving anything real: split one meaningful release into ten trivial ones (a whitespace change, a comment update, a config no-op), each counted as a separate "deploy." Deployment frequency goes up on the dashboard while lead time, failure rate, and actual delivery of value stay flat or get worse, because engineers now spend time manufacturing deploys instead of shipping features. The fix is to treat all four metrics as one scorecard, watch them together, and remember they're diagnostic signals for the underlying practices — trunk-based development, test automation, small batch sizes — not targets to be hit directly. If deployment frequency rises without lead time falling and failure rate holding steady or improving, the number is being gamed, not earned.
Using the four metrics as a team
The practical value of DORA's four metrics is diagnostic, not competitive — they tell you where to look, not how to feel about yourselves relative to some other team. A team with strong deployment frequency but a high change failure rate has an automated-testing or deployment-strategy gap, not a "deploy less" problem: it points at code review depth, test coverage, and progressive rollout patterns like canary releases. A team with fast lead time but slow restore has under-invested in monitoring and observability — they can ship fast but can't see when it broke. Track the four together, on a rolling window (30 or 90 days, not a single release), and read a shift in one metric alongside the other three before drawing a conclusion from it in isolation.
1. What are the four DORA metrics, and which two measure throughput versus which two measure stability? 2. According to DORA's research, do elite performers trade stability for speed, or do they achieve both — and what's the underlying mechanism that makes that possible? 3. What are the Elite-tier benchmark numbers for deployment frequency and change failure rate? 4. Describe a concrete way a team could "game" deployment frequency without actually improving delivery, and explain why that's a Goodhart's Law problem.
Check your answers
- Deployment frequency, lead time for changes, change failure rate, and time to restore service. Deployment frequency and lead time measure throughput; change failure rate and time to restore measure stability.
- They achieve both simultaneously — elite performers deploy far more often than low performers while also failing less often and recovering faster. The mechanism is that small, frequent, reversible changes (enabled by trunk-based development, automated testing, and fast rollback) are individually lower-risk than large, infrequent, batched releases, so higher frequency and higher stability come from the same underlying practices rather than trading off against each other.
- Elite: deployment frequency is on-demand, multiple deploys per day; change failure rate is 0–15%.
- Splitting one meaningful release into many trivial "deploys" (a whitespace change, a no-op config update) inflates the deployment-frequency count on a dashboard without shipping more real value or improving lead time or failure rate. It's a Goodhart's Law problem because the team optimized the measurement itself rather than the underlying delivery practice the measurement was meant to reflect.