A team lead opens the dashboard, sees deployment frequency running at three times a week and a change lead time of two days, and asks the only question that matters in that moment: is that good? On its own, a number is not an answer. It needs a yardstick, and the yardstick most teams reach for is the DORA metrics benchmarks: the Elite, High, Medium, and Low performance tiers the DevOps research programme has published for years. They are useful. They are also more contested, and more easily misused, than the tidy four-row table suggests.
This is a practical read on those benchmarks: what the four tiers look like for each metric, where the thresholds came from, and the significant thing that changed in the most recent research. It builds on the fuller DORA metrics overview, which defines each of the five metrics this post benchmarks.
The DORA metrics benchmarks: four performance tiers
The benchmarks come from the annual State of DevOps research led by the DORA (DevOps Research and Assessment) team, now part of Google Cloud. Across survey years the research sorted teams into four groups (Elite, High, Medium, and Low) by clustering their answers on the core delivery metrics. The bands below are the widely-cited thresholds as published through the 2024 report. Treat them as reference points rather than exact constants, because the precise cut-offs have shifted between report years.
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment frequency | On demand (multiple per day) | Daily to weekly | Weekly to monthly | Monthly to once every six months |
| Change lead time | Less than a day | One day to one week | One week to one month | One to six months |
| Change failure rate | 0 to 15% | 16 to 30% | 16 to 30% | 46 to 60% |
| Failed deployment recovery time | Less than an hour | Less than a day | One day to one week | One week to one month |
| Deployment rework rate | Added in 2024; no universal tier thresholds published yet | |||
Figures are the four-cluster bands from the 2024 Accelerate State of DevOps report. Change failure rate is the one metric that does not cleanly separate the top clusters: high and medium performers share the same 16 to 30% band, which is part of why a single-number tier is a blunt instrument.
What the tiers are actually telling you
The single most important finding behind the benchmarks is that the tiers are not a trade-off. Elite teams are not buying speed by sacrificing stability, or the reverse. They deploy more often and recover faster and fail less, all at once, because the practices that get them there (trunk-based development, test automation, small batches, fast feedback) improve throughput and stability together. That is why deployment frequency and change failure rate belong on the same scorecard: a team that races up the frequency tier while its failure rate climbs has not moved up at all, it has just started shipping bugs faster. Reading the metrics in isolation is the classic misuse, and the tiers do nothing to prevent it.
Reaching the top band is also genuinely uncommon. In the 2024 report only a minority of teams landed in the elite group, which is worth remembering before treating Elite as a baseline expectation rather than an aspiration. Most teams are somewhere in the middle, and the useful question is not “are we elite?” but “are we moving up our own trend line?”
The thing that changed: DORA moved away from the league table
The most recent research changed the frame. The 2025 report, the latest at the time of writing and focused on AI-assisted development, retired the four-tier Elite-to-Low clustering and moved to seven team archetypes defined by the intersection of delivery performance and human factors such as burnout and organisational friction. That is a meaningful signal, not a footnote. DORA itself concluded that ranking every team on a single four-rung ladder was flattening away the context that actually determines whether a team is healthy, and that two teams with identical deployment numbers can be in very different places once you account for how sustainable that pace is.
The practical takeaway is not that the benchmarks are worthless. The metric definitions are unchanged and still the best available measure of delivery throughput and stability. What has aged is the idea that a team's goal is to climb a percentile table. The tiers work as a diagnostic thermometer, a way to sanity-check whether a number is roughly healthy. They fail the moment they become a target, because the fastest way to move up a tier is usually to game the metric feeding it rather than to improve the practice underneath.
How to use benchmarks without gaming them
Compare yourself to yourself first. Your own trend over the last two quarters tells you more than your position against an industry percentile, because it controls for your domain, your release constraints, and your definition of a deployment. For example, a regulated payments team deploying weekly with a 2% failure rate is in a healthier place than a team forcing daily deploys with a 25% failure rate, whatever the frequency tier says. Use the external bands as a coarse check (are we in the right neighbourhood?), then set improvement goals against your own baseline. The mechanics of measuring each metric the same way every time, so the trend is real rather than an artefact of shifting definitions, are covered in how to measure DORA metrics, and the most-benchmarked metric of the five gets its own treatment in deployment frequency.
How CI/CD Watch shows where you stand
CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, derives the DORA metrics from the pipeline and deployment data you already produce, and shows each one against the published performance bands so “is that good?” has an answer in context. Deployment detection is configurable per team, so the frequency and lead-time numbers reflect what actually reaches production rather than treating every workflow run as a deploy. The comparison is to the public DORA bands, not to other customers.
The more useful view is the trend: each metric plotted over time, so you can see whether the practice is improving rather than just where you sit today. The benchmark is context; the trend is the thing you act on. The Free tier covers pipeline-run monitoring across all six providers; the DORA metrics dashboard sits on the paid tiers.
See your numbers against the benchmarks
If you want to know where your delivery performance stands against the DORA bands, connect your providers and CI/CD Watch derives the five metrics and plots them against the published tiers and over your own trend line. Monitoring is free; the DORA dashboard is on the paid tiers. For how each metric is defined and derived from pipeline data, the DORA metrics documentation covers the methodology, and the DORA metrics overview sets out what each metric means.
Benchmark source: the annual DORA State of DevOps research and Google Cloud's Four Keys guidance. Tier thresholds are drawn from the reports through 2024; the 2025 programme moved from four tiers to team archetypes.
CI/CD Watch is built by 3CS Technologies Ltd. It started as an internal tool for tracking pipeline health across a mixed GitHub Actions and Jenkins estate. The same engine now powers the SaaS platform.