The State of Merge Queues 2026

Serialized, always-green merges sound simple, until a flaky failure stalls the whole queue. Here is what they really cost.

Executive summary

A merge queue keeps the main branch always-green by serializing merges. Instead of letting pull requests merge whenever their own checks pass, it batches them, re-runs CI on the combined result, and only merges if the batch is green. It is how busy repos avoid the situation where two individually-passing PRs break each other on main: each was tested against an older trunk, and neither saw the other coming. As trunk-based development spreads, merge queues have become the standard way to keep a fast trunk safe.

The safety has a compute and latency cost that scales with merge volume. Every batch is another full CI run layered on top of the per-PR runs that already happened, so the busiest repos, the ones that need a queue most, also pay the most for it. Worse, a single failure inside a batch, including a flaky non-deterministic one that has nothing to do with any of the changes, bisects or restarts the batch and stalls every PR behind it. The queue that was supposed to keep things moving becomes the thing that stops them.

This report quantifies the re-validation overhead, how much of it flaky failures cause, and why queue throughput is as much a runner-reliability problem as a CI-configuration one. The central finding is that the two biggest costs of a merge queue, the multiplied re-validation minutes and the flaky stalls, are both attacked far more effectively at the runner layer than at the queue-config layer where teams usually look first.

Three numbers frame the picture. Roughly a third of high-velocity repos run a merge queue, and adoption climbs steeply with merge volume because the per-PR conflict risk a queue prevents grows with how many changes land per day. Queue re-validation roughly doubles the CI minutes attributable to each merge before any flakiness is counted. And the change failure rate a queue exists to defend is the 0-15% band that DORA associates with elite performers, which is the bar that justifies the cost in the first place.

For engineering leaders the takeaway is that a merge queue is worth its cost only if the runner layer underneath it is fast and reliable. A queue on cold, flaky runners trades one failure mode for another: it stops PRs from breaking main, but it stalls them in a slow, frequently-restarting train instead. Warm capacity and automatic recovery of transient failures are what let a queue deliver the always-green trunk it promises without the latency and waste that make teams resent it.

Re-validation is the cost nobody budgets for

A merge queue re-runs CI on every batch, so each merged PR carries its own pre-merge run plus a share of the batch run. That second run is invisible in most cost conversations because teams think of CI cost as "minutes per PR" and forget that the queue adds a whole extra validation pass on the combined result. Modeled across typical batch sizes, queue re-validation roughly doubles the CI minutes attributable to each merge before any flakiness is counted.

Batch size is the dial that governs this overhead, and it cuts both ways. A batch of one re-validates every PR individually, which is the safest and most expensive option: maximum re-runs, minimum blast radius. A batch of five amortizes the re-validation run across five PRs, cutting the per-PR overhead, but it raises the blast radius of a single failure, because one bad change can fail the batch and stall four innocent PRs with it. Batch sizing is therefore a direct cost-versus-latency dial, not a set-and-forget setting.

The chart below makes the tradeoff concrete. Direct merging carries only the single pre-merge run; a queue in batches of five adds modest overhead; a queue in batches of one adds the most; and once flaky restarts enter, the per-PR minutes climb past everything else. The practical lesson is that the re-validation cost is real and predictable, so it should be budgeted explicitly rather than discovered on an invoice, and the batch size should be tuned to the repo's actual conflict rate rather than left at a default.

• Queue re-validation models at roughly 2.4x the CI minutes of a single pre-merge run.
• Batch of one minimizes blast radius but maximizes re-runs; larger batches invert both.
• Tune batch size to the repo's real conflict rate rather than leaving it at a default.

Flaky failures are the queue's biggest enemy

In a merge queue a flaky failure is far more expensive than in a plain PR check, because of where it lands. A flaky check on an ordinary PR fails one build, annoys one developer, and clears on a retry. The same flaky failure inside a serialized queue does not fail one build, it stalls every PR behind it in the train, and it often forces a bisect or a full batch restart to find out that nothing was actually wrong. The serialization that makes the queue safe is exactly what makes a single flake catastrophic.

Modeled, transient and flaky failures are the single largest cause of queue stall time, ahead of genuine batch conflicts, cold-start latency, and real test failures combined in many repos. This is the counterintuitive heart of the merge-queue cost story: the queue spends more of its stalled time on failures that were never real than on the genuine conflicts and regressions it exists to catch. The donut chart below shows that split, and the flaky slice dominates it.

Since most of these failures pass on a clean retry, the fix is not better test code, it is automated recovery at the runner layer. When a step fails on a known-transient signal, retrying it on a fresh environment before the queue treats the batch as failed keeps the train moving instead of letting one network blip back up every PR behind it. Crucially this has to happen at the runner layer, below the queue, because by the time the queue sees a red batch it has already paid the stall. Catching the flake before the queue does is what keeps a serialized merge strategy from amplifying every transient hiccup into a queue-wide delay.

• A flake on a plain PR fails one build; the same flake in a queue stalls every PR behind it.
• Modeled, flaky and transient failures are the largest single cause of queue stall time.
• Recovery has to happen below the queue: once it sees a red batch, the stall is already paid.

Cold starts throttle queue throughput

Queue latency is gated by how fast the next batch run can start. A serialized queue drains at the speed of its slowest dependency, and when every batch waits on a cold runner to provision before it can even begin testing, that per-batch cold-start tax compounds across every queued PR. A repo with twenty PRs in the queue pays the cold-start wait twenty times in sequence, and developers experience it as a queue that is mysteriously slow even when no build is failing.

This is the part of queue performance that queue configuration cannot fix. Tuning batch size, adjusting merge methods, or reordering the queue does nothing about the time it takes a runner to come online for each batch. The throughput ceiling is set by the runner layer, and on cold hosted runners it can be the dominant component of end-to-end merge latency even when the tests themselves are fast.

Warm runner capacity removes that per-batch cold-start tax, which is exactly the latency a busy queue feels most. When the next batch run starts in seconds against an already-provisioned runner instead of waiting for cold provisioning, the queue drains at the speed of the tests rather than the speed of the infrastructure. The runner layer, not the queue config, is often the real throughput ceiling, which is why teams that have exhausted queue-level tuning find their next gain by warming the capacity underneath it.

A merge queue defends your DORA numbers

The point of a queue is to keep change failure rate low without slowing delivery, which is precisely the elite balance DORA describes: a change failure rate in the 0-15% band alongside on-demand deploys and a lead time under a day. A merge queue is the mechanism that lets a team hold both at once, preventing the broken-main incidents that spike change failure rate while still letting many changes land per day.

But the defense only holds if the queue itself is reliable. A queue that stalls on flakes, blocks merges for hours, or restarts batches repeatedly trades one DORA failure mode for another. It protects change failure rate at the cost of lead time, turning a fast trunk into a slow one, and a slow trunk is exactly what elite delivery is supposed to avoid. The cure becomes a different disease.

This is why queue reliability is a DORA concern, not just a developer-experience one. The same DORA framing that justifies adopting a queue also condemns an unreliable one, because lead time and change failure rate are both elite-band metrics and a flaky queue improves one by wrecking the other. Defending the DORA numbers means defending the queue's reliability, which routes straight back to the runner layer that determines whether the queue stalls or flows.

Managed runners change the re-validation economics

Because the queue multiplies CI runs, the per-minute rate is paid many times over, so a lower rate compounds across every batch in a way it does not in ordinary CI. A direct-merge repo pays the per-minute rate once per PR; a queued repo pays it on every PR run plus every batch run plus every flaky restart. The same rate reduction that saves a little on direct merges saves a lot on a busy queue, precisely because the queue applies it so many more times.

Managed runners model near 70 percent lower runner cost than hosted (Linux at $0.008/min versus managed at $0.0025/min), and the daily cost chart shows what that compounding looks like for a thirty-merge-per-day repo. Hosted Linux re-validation is already a meaningful daily line item; flaky restarts push it higher; a Windows-heavy mix pushes it higher still; and the managed rate brings it down to a fraction of all of them. For a high-merge-volume repo the per-day gap is the difference between a queue that pays for itself and one that quietly becomes a budget problem.

The reliability story compounds with the cost story. Warm, self-healing capacity attacks the two biggest queue problems at once: cold-start latency, by keeping runners provisioned, and flaky stalls, by recovering transient failures before the queue sees them. That is the combination that makes an always-green trunk affordable rather than merely possible, because it lowers both the per-minute rate and the number of minutes the queue wastes on cold starts and flakes. For the busiest repos, the runner layer is where the merge-queue economics are actually decided.

• Managed runners model near 70% below hosted Linux ($0.008/min vs $0.0025/min), and a queue applies that rate many times per merge.
• Warm capacity removes cold-start latency; self-healing removes flaky stalls.
• On a busy repo the per-day re-validation gap decides whether the queue pays for itself.

Adoption tracks merge volume, not team size

The decision to adopt a merge queue is driven by merge volume far more than by headcount, because the problem a queue solves grows with how many changes land per day. The adoption curve below climbs from a small minority of low-volume repos to a clear majority of the highest-volume ones, and the reason is mechanical: the more PRs that merge per day, the higher the chance that two individually-passing changes collide on main, which is the exact failure a queue prevents.

A low-volume repo can merge directly with little risk, because the window in which two conflicting PRs both pass against the same trunk is narrow and the cost of an occasional broken main is small. A high-volume repo has that window open constantly and pays for every broken-main incident in blocked developers, so the queue's re-validation cost is easily justified by the incidents it prevents. The crossover is where merge volume makes broken-main incidents frequent enough that serialization is cheaper than the firefighting it replaces.

This is why merge queues are a high-velocity phenomenon rather than a universal best practice. For a small team they add cost and latency to solve a problem they rarely have. For a busy monorepo or a fast-moving service team they are close to mandatory, which is why adoption rises so sharply with volume. Knowing where a repo sits on that curve is the first step in deciding whether a queue is worth its re-validation overhead at all.

The runner layer is where queue performance is won or lost

Most teams reach for queue-level controls first when a merge queue underperforms: batch size, merge method, queue ordering, concurrency limits. These help at the margins, but the stall analysis points somewhere else entirely. The dominant causes of stall time, flaky failures and cold-start latency, both live below the queue, in the runners that execute each batch, not in the queue logic that schedules them.

That changes where the highest-leverage interventions sit. A team that has tuned its batch size perfectly but runs on cold, flaky hosted runners will still have a slow, stalling queue, because the queue can only drain as fast and as reliably as the runners underneath it. The queue config sets the policy; the runner layer sets the floor on latency and the ceiling on reliability.

The practical consequence is a reordering of priorities. Before investing further in queue-level tuning, a team should ask whether its runners start warm and recover from transient failures, because those two properties address the two largest stall causes directly. The queue and the runner layer are a system, and for a serialized merge strategy the runner layer is the half that most teams under-invest in and that most determines whether the queue feels fast or feels like a tax.

Recommendations

Budget for re-validation and tune batch size to your conflict rate

Treat the queue's re-validation run as a real, predictable line item rather than a surprise on the invoice. Then tune batch size deliberately: smaller batches lower blast radius at higher cost, larger batches do the reverse. Match the size to the repo's actual rate of batch conflicts instead of leaving it at a default, and revisit it as merge volume changes.

Auto-heal transient failures below the queue

Flaky failures are the largest single cause of queue stalls, and most pass on a clean retry. Recover them at the runner layer, before the queue treats a batch as failed, so a network blip never stalls the train. Catching the flake below the queue is the difference between a queue that flows and one that backs up on every transient hiccup.

Warm runner capacity to remove the per-batch cold start

A serialized queue pays the cold-start tax on every batch in sequence, and queue-level tuning cannot fix it. Keep runner capacity warm so the next batch run starts in seconds, letting the queue drain at the speed of the tests rather than the speed of cold provisioning.

Decide whether you need a queue from your merge volume

A merge queue earns its cost at high merge volume and adds latency for little benefit at low volume. Place your repo on the volume curve before adopting one: if individually-passing PRs rarely collide on main, a queue is overhead, and if they collide constantly, it is close to mandatory.

Lower the per-minute rate that the queue multiplies

Because a queue applies the per-minute rate many times per merge, a lower rate compounds. Managed runners model near 70 percent below hosted Linux and bring warm, self-healing capacity at the same time, attacking the per-minute cost, the cold-start latency, and the flaky stalls together rather than one at a time.

Outlook

Expect merge queues to keep spreading through high-velocity repos as trunk-based development becomes the default, and to keep being absent from low-volume ones for sound reasons. The adoption curve will steepen at the top end rather than flatten across the board, because the value of serialization is a function of merge volume and that distribution is not converging. The interesting shift is not whether more teams adopt queues but whether the teams that have them can make them reliable.

The architectural direction is toward pushing the hard parts of queue performance down into the runner layer. The two costs that define a merge queue, multiplied re-validation minutes and flaky stalls, are both addressed more effectively below the queue than within it, by warm capacity and automatic recovery. As that becomes understood, teams will stop treating the queue config as the whole problem and start treating the runner layer as the half that actually decides whether the queue feels fast.

For most teams the takeaway is that a merge queue is only as good as the runners under it. An always-green trunk that stalls on flakes and crawls on cold starts is not the win it was sold as. The organizations that pair a well-tuned queue with warm, self-healing, low-cost runners will get the change-failure-rate protection a queue promises without surrendering the lead time it was supposed to protect.

Methodology

This report synthesizes publicly available industry data (the DORA State of DevOps research, developer surveys, published CI runner pricing) with Latchkey's own analysis of merge-queue economics. Adoption rates, re-validation minutes, the stall-cause split, and daily costs are modeled estimates derived from typical merge volumes and published runner pricing (Linux at $0.008/min, managed at $0.0025/min), not a primary survey. The DORA change-failure-rate band is used verbatim from the published DORA program. Re-validation overhead and stall splits depend heavily on batch size, flake rate, and merge volume and will vary by repository. 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
• GitHub - Octoverse
• GitHub Actions - billing & pricing
• GitHub Actions documentation

More Latchkey reports