DORA metrics benchmarks are the standard reference point engineering teams use to answer one question: are we actually good at shipping software, or does it just feel that way. The four metrics, deployment frequency, lead time for changes, change failure rate, and time to restore service, come from the DevOps Research and Assessment program’s Accelerate research, led by Nicole Forsgren, Jez Humble, and Gene Kim, and remain the most widely cited delivery benchmark in software engineering. In 2026, understanding these benchmarks requires one important caveat that didn’t exist a few years ago: AI-generated code is starting to distort what the numbers actually mean.
The core benchmark tiers
DORA research classifies teams into four performance tiers based on how they score across the four metrics together, not any single one in isolation. While exact published figures vary slightly by report year, the consistent pattern across DORA’s State of DevOps research looks like this:
Elite performers deploy on demand, multiple times per day, with lead times under one day (and often under one hour for the fastest teams), change failure rates in the single digits to low teens, and recovery times under one hour.
High performers deploy between once per day and once per week, with lead times between one day and one week, moderate change failure rates, and recovery measured in hours.
Medium performers typically deploy once per week to once per month, with lead times of one week to one month.
Low performers deploy less than once every six months, with lead times stretching from one to six months, change failure rates as high as 46 to 64 percent, and recovery times running from a week to a month.
One counterintuitive finding worth internalizing directly: DORA’s own research consistently shows that elite teams are both the fastest and the most stable. Speed and stability aren’t a tradeoff. A high change failure rate doesn’t buy you faster shipping, it just means you’re shipping badly.
Why change failure rate benchmarks confuse people
The distinction between elite and high tiers for change failure rate often uses an overlapping range, which trips people up. What actually separates the tiers isn’t the failure rate number alone, it’s that combined with deployment frequency. An elite team hits a low failure rate while deploying multiple times a day. A high-tier team hits a similar failure rate while deploying less often. Context changes what the same number means.
It’s also worth naming a genuine misconception directly: a 0 percent change failure rate is not the goal, and is often a warning sign. It usually means a team isn’t shipping frequently enough to encounter realistic failure conditions, is defining “failure” too narrowly to count real incidents, or has a blameful culture where incidents go unreported rather than logged.
Read: How to Improve Your DORA Metrics: A Practical Playbook
How AI coding tools are complicating these benchmarks in 2026
This is the part most 2025-era DORA content misses entirely. Deployment frequency and lead time were designed to measure a world where humans wrote all the code. That assumption has partially broken down as AI tools now generate a significant share of committed code at many organizations.
Consider a concrete case: a team that deployed five times per week before adopting AI coding tools now deploys twenty times per week. By DORA’s classification, that looks like a jump from medium to elite performance. But if most of that additional volume is AI-generated boilerplate and low-complexity configuration changes, the team hasn’t tripled its actual capability, it has gotten faster at shipping simpler work. Deployment frequency still reflects real pipeline health, meaning the CI/CD infrastructure genuinely supports frequent releases. But as a proxy for team capability or delivered business value, it’s becoming less reliable without some form of complexity weighting.
Lead time has a similar distortion. When AI generates code in seconds, the coding phase of lead time collapses toward zero, and the metric improves. But that improvement reflects how fast an AI model writes code, not how efficient the human delivery pipeline actually is. It’s also worth being precise about what current research does and doesn’t claim here: DORA’s own reporting explicitly does not assert that AI adoption causes elite-tier performance, only that a correlation exists. Treating that correlation as causation, a common misreading circulating in 2026 content, isn’t supported by DORA’s own research.
Mean time to recovery and change failure rate, by contrast, hold up much better under AI-heavy development, since they measure outcomes in production regardless of who or what wrote the code that shipped.
Practical guidance by team size
Small teams and startups typically see the fastest early wins on deployment frequency, since automating a manual deployment process from monthly to weekly is a bigger relative improvement than an already-elite team squeezing out marginal gains. The most meaningful early investment for a small team is usually CI/CD automation and removing manual sign-off steps, not chasing elite-tier lead time on day one.
Mid-size engineering organizations tend to plateau at the medium-to-high tier because the bottleneck shifts from tooling to architecture: monolithic services and large batch sizes limit how much further automation alone can push deployment frequency. Moving from medium to elite here usually requires structural changes such as trunk-based development, feature flags, and smaller service boundaries, not just faster pipelines.
Large, complex organizations, particularly those with safety-critical or highly regulated systems, may reasonably choose to stay below elite-tier deployment frequency by design, favoring more rigorous change management over raw speed. DORA benchmarks are directional targets, not a mandate that every team must hit elite on every axis regardless of context.
Frequently Asked Questions
What are considered good DORA metrics benchmarks in 2026?
Elite performance generally means deploying on demand (multiple times daily), lead times under a day, change failure rates in the single digits to low teens, and recovery times under an hour. These benchmarks should be read as directional targets rather than fixed pass or fail thresholds, since team context, including regulatory constraints and system criticality, legitimately changes what “good” looks like.
Do AI coding tools automatically improve your DORA metrics?
They can inflate deployment frequency and lead time numbers without necessarily reflecting improved team capability, particularly when AI-generated code accounts for a large share of committed work. Change failure rate and recovery time remain more reliable indicators in an AI-heavy development environment, since they measure production outcomes rather than authoring speed.
Should DORA metrics be used to evaluate individual engineers?
No. DORA metrics are designed and validated as team-level measurements. Attaching them to individual performance reviews creates gaming incentives that make the underlying data unreliable, and undermines the trust needed to use the metrics as genuine improvement tools.
