The 2026 Runner Price Index

The per-minute price of a CI runner across operating systems and providers, indexed to one Linux minute so any team can read its position on the curve at a glance.

Executive summary

The per-minute price of a CI runner is the single number that multiplies through every pipeline a team runs, yet it is rarely benchmarked, because the rates are scattered across operating-system tiers, core counts, and providers. A team can know its monthly bill to the dollar and still have no idea whether the price it pays per minute is competitive, because there is no shared yardstick to read it against. This index collects the rates onto one scale: the per-minute price of compute, normalized so one published Linux minute equals an index of 100.

On that scale the spread is dramatic and, for most teams, surprising. A Windows minute indexes at 200 and a macOS minute at 1000, both straight from published pricing, while self-hosted runners look cheap on paper until idle time and operational overhead are priced back in. The base of the index is the published Linux rate of $0.008 per minute, and every other option is read relative to it. Once the options sit on a common axis, the choices that drive cost stop being a matter of opinion and become a matter of arithmetic.

The managed-runner line indexes well below the hosted Linux base, about 70 percent lower per minute, because it blends warm capacity and right-sizing into a single rate rather than charging the premium tiers a team rarely needs. The practical consequence is that the runner layer, not the workload, is where per-minute price is won or lost. A team can leave its tests, its languages, and its matrix exactly as they are and still move materially down the index by changing nothing but where the minutes run.

This report walks the index tier by tier. It explains why the operating-system premium dwarfs every other lever, why self-hosting almost never costs what the instance invoice says it does, how core count scales price, and why a sub-base managed index compounds at any real run volume. The throughline is that per-minute price is the most portable CI benchmark there is, comparable across teams of any size and any stack, which is exactly what makes an index of it useful.

For engineering leaders the takeaway is concrete. With CI adoption near 76 percent of professional developers, almost everyone is paying some point on this curve, and most are paying more than they need to because they never benchmarked the rate. Reading your blended per-minute price against the Linux base is the fastest diagnostic in this report, and it usually points at the same two fixes: stop paying the OS premium on work that does not need it, and move the base rate itself onto a cheaper runner layer.

The OS premium dwarfs every other lever

Indexed to Linux, Windows costs twice as much per minute and macOS ten times as much, both directly from published pricing. No caching strategy, no sharding scheme, and no runner-size tweak moves the price as much as the choice of operating system does. The OS premium is not a tie-breaker that sits alongside the other levers; it is the dominant term, and on a cross-platform matrix it routinely sets the whole bill.

The reason this surprises teams is that the premium is invisible in a single run. A macOS job and a Linux job both come back green, and nothing in the pull-request view hints that one cost ten times the other. The premium only becomes visible when the minutes are summed and read per OS, which is exactly what the index forces. Once macOS sits at 1000 against a Linux base of 100, the question stops being whether to optimize and becomes which jobs actually earned a macOS minute.

The fix that follows from the index is mechanical. Audit which jobs genuinely require macOS or Windows, signing, packaging, and platform UI tests, and pin everything else, lint, unit tests, and dependency resolution, to Linux. The expensive operating systems end up doing only the work that demands them, and the index drops before a team changes a single line of test code. The chart normalizing each OS to the Linux base makes the size of the prize obvious at a glance.

• Windows indexes at 200 and macOS at 1000 against a Linux base of 100, straight from published rates.
• The premium is invisible per run and only shows up when minutes are summed per OS.
• Moving OS-agnostic work to Linux drops the index with no loss of coverage.

Self-hosted looks cheap until idle is priced in

The raw instance price of a self-hosted Linux runner can undercut the hosted rate, which is why the spreadsheet comparison so often points at self-hosting. But the instance invoice is only one term in the true per-minute price, and in our model it is less than half of it. The rest is overhead that never appears on the bill from the cloud provider yet is just as real on the engineering budget.

The largest hidden term is idle. CI load is spiky, so a fleet sized for peak sits mostly idle off-peak, and a fleet sized for the average starves jobs when the peak arrives. Either way the team pays, in money for capacity it is not using or in developer wait time for capacity it does not have. Layered on top of idle are the operational hours, the image maintenance, the scaling logic, and the patching and security work that a runner fleet demands continuously.

When all of that is folded back in, the idle-adjusted self-hosted rate lands close to the hosted rate it was supposed to beat, and sometimes above it. The chart breaking down the self-hosted effective rate makes the point precisely: raw compute is the minority slice, and idle plus operations is the majority. Self-hosting can still win for a team with a dedicated platform group and steady, high utilization, but the index says it rarely wins on the per-minute price alone.

• Raw instance compute is under half of the true self-hosted per-minute cost in the model.
• Idle and under-utilization is the single largest non-compute term, driven by spiky CI load.
• Operations, maintenance, patching, and security make up the rest, none of it on the cloud invoice.

Larger runners scale price roughly with cores

Moving from a 2-core to a 4-core hosted Linux runner roughly doubles the per-minute rate, which the provider charge is explicit about. The index makes the consequence explicit too: a larger runner only lowers cost when it more than proportionally cuts wall-clock, because the minutes it saves have to outweigh the higher price of each one.

That condition is met less often than teams assume. Many pipelines are bottlenecked on a serial step, a single long test file, or a dependency install that does not parallelize, and throwing cores at a serial bottleneck buys almost nothing while doubling the per-minute price. Reflexive upsizing, reaching for the biggest tier because a pipeline feels slow, is one of the most common ways a bill climbs without a matching gain.

Reading the index by core count discourages that reflex and replaces it with a test. Before upsizing, confirm the work is genuinely parallel and that a larger runner will cut wall-clock by more than the price multiple it adds. The provider comparison chart, which places the larger 4-core hosted rate alongside the standard tier, shows how quickly the per-minute price climbs when a team upsizes by default.

The managed line indexes below the Linux base

The managed runner sits at an index of 31, roughly 70 percent below the published Linux base, which is the one position on the index that falls under the base itself. It gets there by folding warm capacity and right-sizing into a single blended rate rather than charging the premium OS tiers and the largest sizes that drive the hosted curve upward.

A sub-base index matters more than the headline percentage suggests, because per-minute price multiplies through every run a team makes. A team near the Stack Overflow figure of roughly three quarters of developers using CI is paying that multiplier on every push, every branch, and every matrix leg, so a rate below the base compounds into meaningful savings at any real run volume rather than only on the heaviest jobs.

The other consequence is that the managed line moves the base of the index itself, not just the expensive tiers. Even a team that has already done the OS-premium and right-sizing work, and therefore lives mostly on Linux, still pays the Linux base rate on that work. Moving the base from 100 to 31 captures a saving that the OS and sizing levers cannot reach, because those levers reduce how many premium minutes you buy while this one reduces the price of every minute. The per-OS price chart shows the managed rate landing below even the cheapest hosted tier.

Per-minute price is the most portable CI benchmark

Unlike wall-clock or monthly spend, per-minute price is comparable across teams of any size and any workload, which is exactly what makes it a useful index. A startup running a thousand minutes a month and an enterprise running ten million both occupy a single point on the same curve, and that point says something meaningful about whether each is overpaying that neither monthly bill could reveal on its own.

Monthly spend conflates price with volume, so a rising bill can mean either that a team is paying too much per minute or simply running more CI as it grows, and the two demand opposite responses. Wall-clock conflates price with pipeline shape, so a fast pipeline on expensive runners can look healthy while quietly overpaying. Per-minute price strips both confounders away and isolates the one thing a team can benchmark against every other team.

With CI adoption near 76 percent of professional developers, almost everyone is paying some point on this curve, and the fastest way to spot overpayment is to compute your own blended rate and read where it lands against the Linux base. A blended rate well above 100 says the OS premium or reflexive upsizing is dominating; a rate near 100 says the base itself is the next lever; a rate below 100 says the runner layer is already working in your favor.

A blended rate is the number to track, not a single tier

No real team lives at a single point on the index. A typical pipeline mixes cheap Linux unit tests, a handful of expensive macOS or Windows legs, and a few oversized runners for the slow steps, so the number that actually describes the team is the blended rate across all of them, weighted by minutes. That blend is the per-minute figure a leader should track over time.

The blend is also where regressions hide. A team can hold its headline Linux rate constant and still drift upward on the index if the share of macOS minutes creeps up, if more jobs default to a larger runner, or if a matrix quietly adds platform legs nobody pruned. Because each of those changes is invisible in any single run, the blended rate is the only place the drift shows up early enough to correct cheaply.

Computing the blend is simple: total CI spend divided by total minutes, then read against the Linux base of 100. Tracking it the way teams track build duration or flake rate turns the index from a one-time audit into a standing control. When the blend climbs, the cause is almost always one of the three drivers above, and the index points straight at which one.

• The number that describes a team is the minute-weighted blend across all tiers, not any single rate.
• Drift hides in the blend: rising macOS share, default upsizing, or unpruned matrix legs.
• Blended rate equals total spend over total minutes, read against the Linux base of 100.

The index reframes self-hosting as a total-cost decision

Because the index normalizes everything to one per-minute scale, it exposes the comparison that the self-hosting debate usually gets wrong. The honest comparison is not raw instance price against the hosted rate; it is the idle-adjusted, fully loaded self-hosted rate against the hosted rate and the managed rate together, all three read on the same axis.

On that axis the managed line is the one that captures most of the per-minute compute savings self-hosting promises while removing the idle and the operations that drag the self-hosted rate back up. For a team without a dedicated platform group, that is decisive: the comparison stops being instance price versus hosted price and becomes total cost of ownership versus a rate that already folds the operations in.

This is why the index is more than a pricing table. By forcing every option onto a single comparable number, it turns a debate that teams usually argue from intuition into one they can settle from arithmetic, and the arithmetic increasingly favors moving the base rate down rather than taking on a fleet to operate.

Recommendations

Compute your blended per-minute rate and index it to 100

Divide total CI spend by total minutes for a representative month, then read the result against the published Linux base of $0.008. A blended index well above 100 tells you the OS premium or reflexive upsizing is dominating your bill, and it gives you a single number to track as you fix it.

Strip the OS premium off work that does not need it

Audit which jobs genuinely require macOS or Windows and pin everything else to Linux. Reserve the premium tiers for signing, packaging, and platform UI tests. Since macOS indexes at 1000 against Linux at 100, this is the largest single move on the index and it costs no coverage.

Treat upsizing as a test, not a default

Before moving to a larger runner, confirm the work is genuinely parallel and that the larger tier will cut wall-clock by more than the price multiple it adds. Doubling cores roughly doubles the per-minute rate, so an upsize that does not more than halve the time raises your index for nothing.

Price self-hosting on the idle-adjusted rate, not the instance invoice

When you compare self-hosting, use the fully loaded rate that includes idle capacity, operations, maintenance, and patching, not the raw instance price. In the model that overhead is the majority of the true cost, and including it usually erases the apparent advantage over hosted or managed.

Move the base rate down with a managed runner layer

The OS and sizing levers reduce how many premium minutes you buy, but they cannot lower the base rate of the minutes that remain. A managed runner that indexes around 31 moves the base itself, capturing a saving the other levers cannot reach and compounding it across every run.

Outlook

Expect per-minute price to become a standard line on engineering dashboards over the next two years, sitting next to build duration and flake rate. As CI spend has grown into one of the larger tooling line items, the absence of a portable benchmark has become conspicuous, and an index normalized to a Linux minute is the obvious thing to fill that gap. The teams that adopt it will catch upward drift months before it shows up as a budget surprise.

The structural pressure on the index points downward at the base and downward on the premium tiers, but for different reasons. The base rate falls as managed runner layers commoditize warm capacity and right-sizing, pulling the cheapest available minute below the historical hosted floor. The premium tiers stay expensive as long as macOS and Windows hardware remains scarce and licensed, which keeps the OS-audit lever valuable even as the base moves.

The practical forecast for most teams is that the cheapest credible point on the index keeps dropping while the default point, hosted Linux at the base, does not. That widening gap between the default and the achievable is the opportunity. A team that benchmarks its blended rate today and revisits it each year will spend the period steadily walking down the index, while a team that never measures keeps paying the default and absorbing every quiet upward drift as it comes.

Methodology

This index is built on the published GitHub-hosted per-minute rates in the shared pricing spine (Linux 0.008, Windows 0.016, macOS 0.08 per minute) and normalizes them to a Linux base of 100 using the OS cost multiples (Linux 1x, Windows 2x, macOS 10x) from GitHub pricing. The managed line uses the Latchkey blended rate of 0.0025 per minute, a 70 percent reduction versus the blended hosted average, which indexes at 31. Self-hosted effective rates and provider comparisons are Latchkey analysis (modeled) derived from published instance pricing plus idle and operational overhead, and will vary with utilization, fleet sizing, and the cost of the team time that operations consume. CI adoption near 76 percent is from the developer survey. 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
• AWS EC2 On-Demand pricing
• Stack Overflow Developer Survey
• GitHub - Octoverse

More Latchkey reports