The 2026 Deployment Frequency Benchmark

How often teams actually ship by performer tier, what gates the jump to the next band, and why most of the distance is pipeline mechanics rather than process.

Executive summary

Deployment frequency is the most legible delivery metric a team has. It is hard to fake, it is cheap to measure, and it correlates with almost everything else that matters. The DORA program has spent years showing that the teams shipping most often are also the teams with the lowest change-failure rates and the fastest recovery, which inverts the old intuition that speed and stability sit on opposite ends of a seesaw. In practice they move together, because the same habits that let a team ship small changes continuously also keep each change easy to reason about and easy to roll back.

This benchmark places teams into the published DORA performer bands and quantifies the deploy cadence each band sustains. The interesting question is not where elite performers land, which DORA has already documented, it is what gates the jump from one band to the next. The answer is rarely willingness to ship and almost always pipeline friction: slow continuous integration, flaky reruns that erode trust, and manual gates that turn a change that is ready to ship into a change that is queued behind a person. None of those are deploy-button problems. They are mechanics problems, and mechanics are addressable.

When we decompose the elapsed time between a change being ready and that change reaching production, the picture is consistent across tiers. Code review is a real and necessary cost, but it is not where the slow teams lose most of their time. They lose it waiting on continuous integration before a human ever looks at the change, then losing more of it to reruns when a pipeline fails for reasons that had nothing to do with the code. The high and elite tiers have compressed exactly those segments, and the compression is what unlocks the higher cadence rather than any cultural appetite for risk.

Elite cadence is on-demand and multiple times per day. Getting there is less about a deploy button and more about a pipeline that is fast and trustworthy enough that shipping ten times a day feels routine rather than reckless. The teams that reach it have made continuous integration quick enough that the friction of shipping a small change drops below the friction of batching several changes together, at which point batching simply stops, because nobody chooses the slower path when the faster one is reliable.

The encouraging part of this benchmark is that the levers that move a team up a band are well understood and cheap relative to their payoff. Faster pipelines, automated recovery for transient failures, and a runner layer that keeps high-volume CI affordable are pipeline hygiene rather than a transformation program. A team does not need to reorganize to climb a tier. It needs to find the minutes it is losing to mechanical waste and reclaim them, and this report is a map of where those minutes hide.

Elite cadence is on-demand, not scheduled

The DORA elite band for deployment frequency is On-demand (multiple per day), which in practice means several production deploys on a normal working day rather than a release event marked on a calendar. The teams that hit it have stopped batching releases entirely. Small changes flow to production continuously instead of accumulating into a large, risky weekly or fortnightly push that everyone braces for.

This matters because batch size is the hidden variable behind change-failure rate. A deploy that carries one small change is easy to review, easy to reason about, and easy to roll back if something goes wrong. A deploy that carries two weeks of accumulated changes is none of those things, and when it fails the team cannot quickly tell which of the many changes caused the failure. On-demand cadence is therefore not just faster, it is safer, which is why the same teams that ship most often also recover fastest.

The cadence ladder in our modeling is steep. A low performer sits below one deploy per day, a medium performer around two, a high performer above four, and an elite performer above seven. The gap from bottom to top is roughly an order of magnitude, and almost none of it is explained by how badly each team wants to ship. It is explained by how long their pipeline takes and how much they trust it, which the next findings quantify directly.

CI wait is a third of the low-tier interval

For a low performer, roughly a third of the elapsed time between a change being ready and that change reaching production is spent waiting on continuous integration, before any human looks at the change. That is the single most compressible part of the interval, and it is pure pipeline mechanics rather than process. Nobody decided that waiting on CI should take that long; it accreted as the test suite grew and nobody defended the budget.

When we break down the interval for a low-tier team, code review and approval take the largest single share, manual release gates take a meaningful slice, and rework after failed checks accounts for the rest. The review portion is real work that resists pure automation, but the CI-wait, gate, and rework portions are all mechanical. Together they are the majority of the interval, and together they are exactly the segments that the high and elite tiers have compressed.

The practical implication is that a team trying to ship more often should look at its pipeline before it looks at its process. Speeding up review is a human and cultural project that takes quarters. Cutting CI wait in half is a configuration project that can take days, and it frees up a larger share of the interval. Teams that invert this order, reorganizing their review process while leaving a twenty-seven-minute pipeline untouched, tend to be disappointed by how little their cadence moves.

• CI wait is mechanical and compressible without changing how the team reviews code.
• Manual release gates and post-failure rework are also mechanical, not review-bound.
• Code review is the one segment that resists automation, so it should not be the first place a team looks for cadence.

Faster pipelines pull teams up a band

The correlation between median pipeline time and deploy cadence is steep and consistent. In our modeling a low-tier team runs a pipeline near twenty-seven minutes, a medium team around eighteen, a high team near eleven, and an elite team around six minutes on warm managed runners. The pipeline-time ladder and the cadence ladder are the same ladder viewed from two angles.

There is a threshold effect hiding in that curve. Teams that get end-to-end continuous integration under roughly ten minutes tend to start shipping multiple times a day almost as a side effect, because the friction of shipping a small change drops below the friction of holding it back to batch with others. Above that threshold, batching feels efficient; below it, batching feels like pointless delay, and the team stops doing it without anyone mandating the change.

This is why investing in pipeline speed often produces a cadence improvement that looks disproportionate to the engineering effort. Cutting a pipeline from eighteen minutes to nine does not merely halve a wait, it crosses a behavioral line. The team begins to treat production deploys as routine and small, which then feeds back into faster review and lower change-failure rates, compounding into the next band.

Flaky tests quietly cap cadence

A pipeline that fails one run in twenty for non-code reasons teaches a team to deploy less often, because each red build burns time and, worse, burns trust. After enough spurious failures an engineer stops believing the red check, which is the most expensive failure mode in continuous integration: a signal nobody trusts is a signal nobody acts on, and the team drifts back toward batching to amortize the pain.

When we ask teams what most constrains their cadence, slow or queued CI is the top answer, flaky tests and reruns are a close second, manual approval gates are third, and fear of breaking production trails behind. The first two answers, which together are the clear majority, are both runner-layer problems rather than test-quality problems. They are about how fast the pipeline runs and how reliably it returns a trustworthy result.

Self-healing runners attack the flaky portion directly. When a step fails on a known-transient signal, a network blip pulling a dependency, a registry timeout, an out-of-memory kill on an undersized runner, the platform retries it on a fresh environment automatically before a human ever sees a red check. The failure never reaches the pull request, the engineer never loses trust, and the cadence that flakiness was quietly capping is released without anyone loosening a single test.

• Flakiness erodes trust in the red check, which is the signal cadence depends on.
• Slow CI and flaky reruns are the top two stated cadence blockers and both are runner-layer issues.
• Auto-healing transient failures removes the drag without weakening the test suite.

Manual gates batch what the pipeline could ship continuously

A meaningful slice of the low-tier deploy interval is spent in manual release gates: a person who must click approve, a change-advisory step, a scheduled deploy window. Each gate is individually defensible and collectively expensive, because every gate reintroduces batching. Changes pile up behind the gate, and the deploy that eventually passes through it carries more risk than any single change would have.

The high-cadence pattern is not to remove every gate, it is to make the common path gateless and reserve human approval for the genuinely risky minority. Routine changes that pass a trustworthy pipeline ship automatically; changes that touch a sensitive surface route to a human. This keeps the safety where it earns its cost and removes it where it only adds latency, which is the opposite of the blanket gate that slow teams apply to everything equally.

The dependency here is trust in the pipeline. A team cannot make the common path gateless if it does not believe its own green check, which loops back to flakiness and speed. This is why the cadence levers reinforce each other: a fast, trustworthy pipeline lets a team safely remove gates, removing gates raises cadence, and higher cadence shrinks batch size, which makes each change safer and the pipeline easier to trust.

Managed runners make high cadence affordable

Shipping ten times a day means running the pipeline ten times a day, and that volume is exactly where runner cost compounds. A team that climbs from one deploy a day to ten has, to a first approximation, multiplied its CI minute consumption by the same factor, and on hosted runners that shows up directly on the monthly invoice. Cadence that arrives as a sharply higher bill tends not to survive the next budget review.

A managed warm pool keeps each of those runs fast and cheap. Warm runners remove the cold-start penalty that would otherwise tax every one of the ten daily runs, and a managed per-minute rate lands roughly 69% below hosted cost, so the higher run volume does not translate into a proportionally higher bill. The economics of high cadence and the economics of managed runners point in the same direction.

This is the quiet enabler behind the elite band. The teams that ship continuously are not paying a premium for the privilege; they have made each individual run cheap enough that running many of them is affordable. Without that, the cadence ambition collides with the finance reality, and the team rations deploys to control spend, which is precisely the batching behavior that drops it back down a tier.

The blockers to cadence are mechanical, and that is good news

Across every tier, the factors that hold a team back from the next band are dominated by mechanics rather than mindset. Slow and queued continuous integration leads the list of stated blockers, flaky tests and reruns follow, manual approval gates come next, and fear of breaking production trails. Three of those four are pipeline and runner problems with known, cheap fixes. Only the last is a cultural concern, and it largely dissolves once the other three are addressed.

This is genuinely good news for an engineering leader, because mechanical problems are tractable in a way that cultural ones are not. A team cannot will itself into a higher band, but it can cache its dependencies, speed up its pipeline, auto-heal its transient failures, and reserve its gates for the changes that need them. Each of those is a finite, scoped piece of work with a measurable payoff, and together they move the cadence needle further than any motivational push.

The teams that climb fastest treat cadence as an outcome of pipeline health rather than a target to be hit directly. They do not set a deploy-frequency goal and exhort people to ship more. They fix the mechanics that make shipping slow and risky, and the cadence rises on its own, because once shipping a small change is fast and safe, people do it constantly without being asked.

Recommendations

Set an explicit pipeline-time budget and defend it

Pick a target for end-to-end CI wall-clock time, ideally under ten minutes, and treat regressions against it as bugs. Cadence tracks pipeline time closely, so the pipeline budget is the most direct lever you have on deploy frequency. A budget nobody owns is a budget that erodes as the test suite grows.

Compress CI wait before reorganizing review

CI wait is the most compressible segment of the deploy interval and it is pure mechanics. Cache dependencies, shard tests with impact analysis, and right-size runners before launching a process-reform effort on review, which is slower to change and a smaller share of the interval for most low-tier teams.

Auto-heal transient failures so the green check stays trustworthy

Flakiness caps cadence by eroding trust in the red check. Retry transient failures on a fresh environment automatically, before a human is pulled in, so that a network blip or registry timeout never teaches the team to batch its deploys to amortize the pain.

Make the common deploy path gateless and reserve human approval for risk

Blanket manual gates reintroduce batching on every change. Let routine changes that pass a trustworthy pipeline ship automatically and route only the genuinely sensitive changes to a human, so the safety lands where it earns its cost rather than on everything equally.

Use a managed warm pool so higher cadence does not arrive as a higher bill

Ten deploys a day means ten pipeline runs a day, and on hosted runners that compounds directly into spend. A managed warm pool keeps each run fast and prices the minutes roughly 69% below hosted cost, so the team can raise cadence without rationing deploys to control budget.

Outlook

Expect the spread between bands to widen rather than narrow through 2026 and into 2027. The levers that move a team up a tier compound: a faster pipeline raises cadence, higher cadence shrinks batch size, smaller batches lower change-failure rate and speed recovery, and a healthier delivery record makes the team comfortable removing more gates, which raises cadence again. Teams already in the high and elite bands feel that flywheel accelerate, while teams that leave the mechanics unaddressed feel the opposite compounding as their test suite and approval surface grow.

The runner layer is becoming the decisive factor in where a team lands. As warm pools, automated recovery, and managed per-minute economics converge into an expected baseline, the teams that adopt them get fast, trustworthy, affordable pipelines almost by default, and the cadence follows. The teams still hand-rolling self-hosted fleets or paying full hosted rates for high-volume CI find that the cost of high cadence keeps them rationing deploys, which pins them below the band their engineers are otherwise capable of reaching.

For most teams the practical takeaway is that deployment frequency is not a goal to be exhorted, it is an outcome to be engineered. Fix the pipeline, heal the flakes, reserve the gates, and keep the runner layer cheap, and the cadence rises on its own. The organizations that internalize that will spend the next two years climbing bands while their peers keep setting deploy-frequency targets they cannot mechanically reach.

Methodology

This benchmark maps modeled deploy-cadence and pipeline-time figures onto the DORA program's published performer bands; the band definitions (elite deployment frequency, lead time, and recovery) are used verbatim from DORA. Deploys-per-day, interval splits, pipeline times by tier, and blocker shares are illustrative Latchkey estimates derived from typical pipeline shapes, not a primary survey, and are intended to show direction and magnitude rather than a precise population value. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• DORA State of DevOps Report
• Stack Overflow Developer Survey
• GitLab DevSecOps Survey
• GitHub Actions - billing & pricing

More Latchkey reports