Deployment Frequency: What 'Elite' Really Means
WHAT 'ELITE' REALLY MEANS
DORA's deployment-frequency bands, what 'on demand' actually means, why batch size is the real story, and the honest caveats behind the word 'elite.'
The band we grade against.
Illustrative example
TL;DR: DORA's last published bands (2024): elite deploys on demand (multiple times a day), high daily-to-weekly, medium weekly-to-monthly, low monthly-to-every-six-months. The cadence itself is downstream: deployment frequency is really a batch-size meter, and small batches are why elite teams are also the stable ones (~5% change failure rate). The caveats are real, though. It's survey data, "a deploy" is fuzzier than it sounds, DORA retired the tiers in 2025, and a no-op deploy loop can fake the whole thing.
"How often do you deploy?" is the closest thing engineering has to a one-question health check. Not because the number itself pays the bills, but because you can't fake it for long without actually being good: deploying on demand requires small changes, real tests, an automated pipeline, and the organizational nerve to use them. That's also why it's worth understanding exactly what the famous bands do - and don't - say.
What are the deployment frequency benchmarks?
The 2024 DORA report, the final year of the elite/high/medium/low model, banded deployment frequency like this:
| Band | Deployment frequency | Share of teams (2024) |
|---|---|---|
| Elite | On demand (multiple deploys per day) | 19% |
| High | Daily to weekly | 22% |
| Medium | Weekly to monthly | 35% |
| Low | Monthly to every 6 months | 25% |
Two honest readings of that table. First: elite is not exotic. Roughly one team in five surveyed reports deploying on demand. If you're shipping monthly on a standard web stack, you're in the bottom half, and the teams above you aren't taking more risk than you. They're taking less, in smaller pieces.
Second: the median team is medium. If that's you, you're normal, with a well-lit staircase above you that a fifth of the industry has already climbed.
What "on demand" actually means
Not a quota. Nobody elite is deploying at 4pm because the dashboard demands a second deploy. "On demand" means the pipeline is never the reason a finished change waits: when a change is ready, it ships, and multiple changes happen to be ready most days. It's a capability claim - automated pipeline, deploy-safe test suite, rollback path - stated as a cadence.
That reframe matters because it tells you what to fix. A team deploying weekly doesn't have a "deploy more often" problem; it has some specific reason finished work waits: a manual release checklist, a Friday train, a batching habit, an approval step from 2019 nobody has re-questioned. Find the reason; the frequency follows.
Why batch size is the real story
Deployment frequency, held against a roughly constant rate of code production, is just the inverse of batch size. Deploy monthly and each deploy carries a month of changes; deploy daily and it carries a day. That single variable drags most of delivery behind it:
- Review quality. The SmartBear/Cisco research found reviewers are effective on 200-400 lines at a time, with defect discovery collapsing at higher rates. Small deploys are made of small PRs, the kind that actually get read. LinearB's 2026 benchmarks (8.1M+ PRs, 4,800+ teams) put elite PR size under 100 changed lines.
- Blast radius. When a 10-change deploy fails, the suspect list has 10 names; when a 300-change deploy fails, good luck with the lineup. This is why the DORA data shows speed and stability rising together: elite performers pair on-demand deployment with ~5% change failure rates, while low performers pair semi-annual deploys with ~40%. Big batches aren't cautious. They're risk, fermenting.
- Recovery. Small deploys make "roll it back and re-ship the fix" a five-minute decision instead of an incident-bridge negotiation about which of 300 changes to sacrifice.
- Everything upstream. The habits that shrink deploys - one logical change per PR, fast pickup, reviews that move - are the same ones that shorten every stage of cycle time.
The honest caveats
It's survey data. DORA's bands come from practitioner self-reports, not pipeline telemetry. Measure your own number from the deploy log before locating yourself on the table. The gap between the standup answer and the log is routinely a full band.
"A deploy" is fuzzier than the table admits. Microservices teams rack up deploy counts a monolith team structurally can't, for identical batch discipline per service. Mobile teams are gated by app-store review regardless of virtue. Compare against your own history and your own architecture first; the published band is orientation only.
The tiers are retired. DORA's 2025 report replaced elite/high/medium/low with seven team archetypes. The 2024 table is the last of its line: still the most useful single orientation in the industry, no longer a live standard. Anyone certifying you "DORA elite" in 2026 is grading against a rubric its authors withdrew.
Goodhart is watching. Make deployment frequency a KPI and you will get deploys: no-op releases, config-only pushes, one change split across five ceremonial ships. The number is only meaningful as a consequence of small batches and a trusted pipeline. Pay for the number and you'll get the number, minus the meaning.
Elite is not every team's target. Firmware, safety-critical, heavily regulated: real constraints exist. The right goal there is the smallest safe batch and the most automated pipeline the constraint allows, rather than a cadence copied from a SaaS blog.
How to move up a band
In leverage order: make the pipeline boring (automated, rollback-ready, no manual checklist); shrink the PRs feeding it; kill the batching rituals (release trains, deploy-freeze Fridays that turn Monday into a demolition derby); then let frequency rise as a side effect. If your team defends the monthly cadence as the safe option, the argument that actually lands is in you ship once a month and call it stability. The fear is real, but batching is what caused it.
Measure it from the log and watch the trend over weeks. Watch change failure rate alongside it, because frequency purchased with stability is the one trade the whole scoreboard exists to catch. The full four-key context, including what the other three metrics are doing while you push this one, is in DORA metrics explained.
Deploy frequency earned its place as the headline delivery metric because it's hard to fake honestly and easy to measure honestly. Just remember which direction the causality runs: elite teams aren't healthy because they deploy daily. They deploy daily because they're healthy - and every piece of that health is buildable.
Frequently asked
What is a good deployment frequency?
In DORA's 2024 bands (the final year of the tier model) elite teams deploy on demand (multiple times a day), high performers daily to weekly, medium weekly to monthly, and low monthly to every six months. About 19% of surveyed teams reported the elite pattern.
Why does deployment frequency matter?
Mostly because it's the inverse of batch size. Frequent deploys mean small changes: easier to review properly, smaller blast radius when one fails, faster to diagnose because less changed. The cadence is a proxy for the practices underneath it.
Is deploying multiple times a day realistic for every team?
No, and DORA never claimed it was. App-store review gates mobile releases; firmware and regulated environments have real constraints. The practices (small batches, automated pipelines, fast feedback) transfer even where the literal cadence doesn't. Chase the capability, not the label.
Can you increase deployment frequency without increasing risk?
That's the core DORA finding: speed and stability rise together. Smaller batches fail less and recover faster: elite performers pair on-demand deploys with roughly 5% change failure rates. The risk isn't in deploying often; it's in the big batches that infrequent deploying creates.