The State of CI Runners 2026

The runner is the unit of CI compute, and the two quiet decisions of how to size it and how to have it ready determine most of what a pipeline costs and how fast it feels.

Executive summary

The runner is the unit of CI compute. Every job a pipeline runs lands on one, and in 2026 teams have three broad ways to get one: a fully managed runner, a provider-hosted runner, or a self-hosted runner on their own capacity. Each trades off cost, control, and operational load differently, and the most striking thing about the current landscape is that very few teams commit to a single model. The default is a blend, with different parts of the pipeline routed to whichever runner model fits that slice best.

That blend is the backdrop, but it is not where the interesting decisions live. This report charts the landscape and then digs into the two choices that quietly determine both cost and developer experience: how big a runner to ask for, and how to have it ready when a job arrives. Right-sizing decides whether a team pays for cores its jobs never touch. Readiness, the combination of warm pools and autoscaling, decides whether a developer waits seconds or minutes for a job to start. Neither shows up on most dashboards, which is exactly why both go wrong so often.

The throughline is that queue time is the cost teams feel most and measure least. A developer does not experience a runner as a per-minute rate; they experience it as a wait between pushing and seeing the pipeline move. Under burst load on cold-start capacity that wait can stretch to many seconds, and it compounds across a day of pushes into a real drag on momentum. Warm pools and autoscaling that keep capacity ready collapse that wait, which is where managed runners with warm pools pull ahead of both bare hosted runners and hand-rolled self-hosted fleets.

Three numbers frame the year. Median cold-start queue time under burst load runs to roughly thirty-eight seconds on hosted runners with no pool, which is the wait a warm pool largely removes. A warm pool that absorbs the burst cuts queue time by around ninety percent in our modeling. And teams without a warm pool tend to over-provision by a factor of roughly two and a half to avoid queueing, paying for idle headroom instead of paying for managed readiness.

The practical conclusion is that the runner model matters less than the two decisions layered on top of it. A team on any sourcing model can right-size its jobs and can manage readiness, but on a self-hosted fleet both are continuous engineering work, while on a managed runner with a warm pool they come integrated. That is why the landscape is consolidating not around a single sourcing model but around runners that fold sizing, readiness, autoscaling, and recovery together so a team does not have to assemble them by hand.

Most teams run a blend, not a single model

The clean managed-versus-hosted-versus-self-hosted framing rarely survives contact with a real organization. In practice teams route latency-sensitive or simple jobs to hosted or managed runners, where pickup is fast and there is nothing to maintain, and reserve self-hosted capacity for the workloads that genuinely need it: jobs that require private network access, special hardware, a GPU, or a compliance boundary that cannot leave their own account.

The sourcing chart reflects that pragmatism. Provider-hosted runners carry the plurality of CI minutes because they are the path of least resistance, self-hosted runners hold a substantial share driven by the special-requirement workloads, and managed runners hold a growing slice for teams that want hosted convenience at closer to self-hosted economics. No single model dominates, because no single model is best for every slice of a pipeline.

The real question, then, is not which model a team should standardize on but which model should own each slice of the pipeline. A team that thinks in those terms routes deliberately, putting the cheap fast majority of jobs on managed or hosted capacity and confining self-hosted complexity to the jobs that truly require it. A team that does not ends up with self-hosted sprawl carrying work that had no reason to be there, paying the ops cost of self-hosting for jobs a managed runner would have handled cheaper.

Right-sizing is the cheapest optimization nobody runs

A large share of jobs are pinned to a runner size far bigger than they use, because defaults are sticky and almost nobody profiles. A workflow gets created on a four-core runner because that is what someone copied, the job actually saturates one core for two minutes, and the other three cores are billed and idle on every single run thereafter. Multiplied across a pipeline and a year, that is a quiet, permanent overcharge nobody is looking at.

The sizing chart shows the distribution of jobs across size classes, and the telling detail is how much sits at four cores and above relative to what the jobs actually demand. The mismatch is rarely deliberate. It is the residue of defaults and copy-paste, frozen in place because changing a runner size feels risky and because the cost of the oversize is spread thinly enough across the bill that no single run looks expensive.

Matching runner size to the real CPU and memory footprint of a job is the cheapest optimization available, because it removes paid-for cores that never do work with no change to the pipeline beyond the size label. The barrier is purely visibility: a team that profiles its jobs almost always finds it is over-provisioned somewhere, and the fix is a one-line edit. The reason it goes unrun is not difficulty, it is that nobody measured, which is the same root cause behind most CI waste.

• Runner sizes are usually inherited from defaults and copy-paste, not chosen from a profile.
• An oversized runner bills idle cores on every run, a cost spread thinly enough to stay invisible.
• Right-sizing changes only the size label, so the payoff-to-effort ratio is unusually high.

Queue time is the cost developers feel most

Cold-start queueing under burst load is where developer experience degrades fastest, and it is almost never on a dashboard. When a wave of pushes arrives, a morning rebase across the team, a merge-queue flush, a CI-wide retrigger, demand spikes faster than cold capacity can come online, and jobs sit in queue waiting for a runner. The developer sees a pipeline that has not started, and that wait is pure dead time with no work being done.

The queue-time chart traces how readiness strategy changes that wait. Cold start with no pool is the worst, with a median around thirty-eight seconds under burst that stretches much longer at the tail. Reactive autoscaling helps but structurally lags the spike, because it only begins provisioning after the demand has already arrived, so the first jobs in a burst still wait. A small warm pool cuts the wait sharply, and a properly sized managed warm pool brings it down to a few seconds, effectively an instant pickup.

This is the single biggest lever on perceived CI speed, and it is largely orthogonal to how fast the tests themselves are. A team can spend weeks shaving minutes off its test suite and still feel slow if every push waits in queue first, and conversely a team with ordinary tests but instant pickup feels fast. Because queue time is rarely measured, teams routinely optimize the tests when the wait was the problem, which is why surfacing and then removing queue time has such an outsized effect on how the pipeline feels.

Reactive autoscaling structurally lags the spike

Autoscaling sounds like the complete answer to bursty CI load, and it is genuinely useful, but reactive autoscaling has a structural limitation that warm pools exist to solve. By definition, a reactive autoscaler reacts: it observes demand, decides to add capacity, and then waits for that capacity to boot and register before it can run anything. During that provisioning window the burst is already happening, and the early jobs in it wait.

That lag is not a tuning problem that better thresholds will fix; it is inherent in provisioning after the fact. The cold-start time to launch an instance, boot it, install the runner, and register it is paid in full at exactly the moment demand is highest. The queue-time chart shows reactive autoscaling landing well above the warm-pool options for precisely this reason: it eliminates the steady-state over-provisioning problem but not the burst-onset wait.

A warm pool inverts the timing. Instead of provisioning in response to demand, it keeps a small amount of ready capacity online ahead of demand, so the first jobs in a burst land on a runner that already exists while the autoscaler quietly refills the pool behind them. The two work best together: the warm pool absorbs the onset of the spike, and autoscaling handles the sustained body of it. Readiness for the burst and elasticity for the volume are different jobs, and a mature runner layer does both.

Over-provisioning is the tax teams pay to avoid queueing

Without a warm pool, the usual defense against queueing is brute force: keep far more capacity running than steady-state demand requires, so that when a burst arrives there is already enough idle capacity sitting around to absorb it. Teams that do this over-provision by roughly a factor of two and a half in our modeling, which means the majority of what they pay for at any given moment is not running a job.

That headroom is billed whether or not it runs a job, so the choice becomes explicit and uncomfortable: pay for idle capacity, or pay for developer wait time. A team that sizes for peak pays for idle most of the day; a team that sizes for average starves jobs during peak. There is no setting on a fixed fleet that escapes the tradeoff, because the load is spiky and the capacity is static, so one of the two costs is always being paid.

The utilization chart shows what managed readiness does to that tradeoff. With a warm pool and autoscaling managing capacity, the large majority of paid capacity is doing active work, a modest slice is ready headroom deliberately kept warm for the next burst, and only a small remainder is idle or draining. The over-provisioning tax does not vanish entirely, because some headroom is the whole point, but it shrinks from the dominant cost to a managed minority, which is the difference between paying for readiness and paying for waste.

• A fixed fleet sized for peak is idle most of the day; sized for average it starves jobs at peak.
• Spiky load against static capacity means one of idle cost or wait cost is always being paid.
• Managed readiness shrinks idle headroom from the dominant cost to a deliberate minority.

Isolation and recovery ride along with how the runner is provisioned

The readiness story is usually told in terms of speed and cost, but the way a runner is provisioned also decides two things that matter just as much: isolation and recovery. A runner that is created fresh for each job and torn down afterward gives per-job isolation as a side effect, which means one job cannot observe or poison the next, eliminating both a class of security exposure and a class of flaky failures caused by state bleeding between runs.

Recovery rides along the same way. When the runner layer is the thing provisioning environments, it is also the natural place to retry a step that failed on a transient signal, a registry timeout, a network blip, an out-of-memory kill, on a clean new environment before a human ever sees a red check. The mechanical majority of flakes never reach the pull request, and the minutes spent become recovery minutes rather than wasted ones, all because the runner already knows how to stand up a fresh environment on demand.

This is why provisioning strategy is not a narrow performance concern. The same ephemeral, on-demand provisioning that delivers instant pickup from a warm pool also delivers per-job isolation and automatic recovery, because all three are downstream of the runner creating and destroying environments cleanly. A team that gets readiness right by adopting that kind of runner tends to get isolation and recovery for free, which is part of why the managed warm-pool model leads on more than just queue time.

Managed warm pools fold readiness, autoscaling, and recovery together

The pieces teams assemble by hand on self-hosted fleets come integrated on managed runners: a warm pool for instant pickup, autoscaling for the sustained burst, ephemeral teardown for isolation, and automatic recovery of transient failures. On a self-hosted fleet each of those is a separate project with its own maintenance burden, and keeping all four working together as the platform evolves is continuous engineering work that competes directly with shipping product.

That integration is what the charts in this report are circling from different angles. The queue-time chart shows the warm pool winning on pickup, the utilization chart shows it winning on the idle-versus-wait tradeoff, and the readiness-and-recovery discussion shows the same provisioning model delivering isolation and self-healing as byproducts. They are not four separate advantages; they are four views of one architectural choice about how runners are created and kept ready.

This is why managed runners with warm pools lead on both queue time and utilization without an ops team behind them, and it targets roughly 69 percent below GitHub-hosted rates while doing it. The relevant comparison is not instance price versus hosted price; it is the assembled, maintained system of pool plus autoscaler plus isolation plus recovery versus a runner layer that ships all of it integrated. For any team without a dedicated platform group, and often even for those that have one, the integrated version is the one that actually gets and stays built.

Recommendations

Route each slice of the pipeline to the model that fits it

Do not standardize on a single sourcing model; decide which model owns each slice. Put the cheap, fast majority of jobs on managed or hosted capacity and confine self-hosted complexity to the jobs that genuinely need private network access, special hardware, or a compliance boundary. Self-hosted sprawl carrying ordinary work is paid ops cost with no payoff.

Profile jobs and right-size the runner

Right-sizing is the cheapest optimization available and almost nobody runs it. Profile the actual CPU and memory footprint of each job and match the runner size to it, removing paid-for cores that never do work. The change is a one-line size label, and the barrier is purely visibility, so the first profile a team runs usually pays for itself.

Put queue time on a dashboard, then attack it with readiness

Queue time is the cost developers feel most and measure least. Capture queue-to-start latency as a metric so the wait stops being invisible, then close it with warm capacity rather than faster tests. A team that cannot see queue time keeps optimizing a test suite that was never the bottleneck.

Pair a warm pool with autoscaling, not one or the other

Readiness for the burst onset and elasticity for the sustained volume are different jobs. A warm pool absorbs the first jobs in a spike while the autoscaler refills behind them; reactive autoscaling alone structurally lags the onset. Use both together so the early jobs land on capacity that already exists and the body of the burst still scales out.

Treat provisioning as the source of isolation and recovery too

Choose a runner that provisions fresh per job and tears down afterward, because the same ephemeral provisioning that delivers instant pickup also delivers per-job isolation and automatic recovery of transient failures. Getting readiness right with that kind of runner tends to hand you a security and reliability improvement for free, which is why the managed warm-pool model leads on more than queue time alone.

Outlook

Expect the runner landscape to keep consolidating not around a single sourcing model but around integration. The blend of hosted, self-hosted, and managed runners is here to stay, because different workloads genuinely want different things, but the advantage is shifting decisively toward runner layers that fold sizing guidance, warm-pool readiness, autoscaling, isolation, and recovery into one system rather than leaving teams to assemble them. Assembling those pieces by hand is exactly the work most teams cannot keep funded.

Queue time is likely to become the metric teams finally start watching, the way build duration became a tracked number a few years ago. As more teams instrument the queue-to-start interval, the over-provisioning tax and the cold-start wait stop being invisible and start being optimized, and the readiness strategies that collapse them, warm pools backed by autoscaling, move from a managed-runner differentiator to a baseline expectation.

For most teams the practical takeaway is that the runner model is the smaller decision and the two layered choices are the larger ones. Size the runner to the job, keep capacity ready ahead of the burst, and let the same ephemeral provisioning deliver isolation and recovery. The organizations that do this, most easily by adopting a managed warm-pool runner that ships it integrated, will spend the next two years with fast, cheap, predictable CI while their peers keep paying either the idle tax or the wait tax they could have removed.

Methodology

This report synthesizes publicly available industry data with Latchkey's own modeling of runner sizing, queue time, and capacity utilization. Figures labeled "modeled" are illustrative estimates derived from public pricing and representative pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Latency figures are modeled under burst-load conditions and will vary by workload. 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

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

More Latchkey reports