The 2026 CI Minutes Benchmark

A per-headcount baseline for how many CI minutes an organization actually burns each month, and how steeply that volume bends upward as the team grows.

Executive summary

CI minutes are the unit of consumption that drives the entire CI bill, yet most organizations only discover their monthly volume after a surprising invoice. Compute is metered by the minute, the meter runs on every push, and the total accumulates quietly in the background while the team focuses on shipping. By the time the number is large enough to notice, it has usually been large enough to matter for a while. This benchmark exists to surface that number before the invoice does.

We set a baseline: the modeled CI minutes an organization burns per month at each size band, so a team can place its own consumption on a curve rather than guessing whether it is high. The value of a benchmark is comparison. A raw figure of a hundred thousand minutes a month means nothing in isolation; the same figure means a great deal once you know whether a comparable org runs half that or twice that. The bands in this report give that frame of reference.

The defining feature of the curve is that it bends upward rather than tracking headcount in a straight line. Minutes do not scale one-to-one with engineers because larger organizations run more branches, more matrix dimensions, and more frequent pipelines per person. Our model puts a 100-engineer org at roughly 128,000 minutes a month, and consumption grows about 4.2 times as a codebase scales past fifty engineers, faster than the headcount that nominally drives it. That curvature is the single most important fact for anyone forecasting CI cost.

Pricing those minutes at the published Linux rate exposes the bill behind the volume, and it is where the managed-runner line matters most. The same minutes billed at a per-minute rate about 70 percent lower turn a steep cost curve into a manageable one, and it does so without anyone running fewer pipelines, caching differently, or changing a single test. The minutes are the same; only the price of each one changes.

The benchmark is unusually broad in its applicability. Because CI adoption sits near 76 percent of professional developers, nearly every organization is consuming minutes on some version of this curve, regardless of stack or domain. Monthly minute volume is therefore one of the few CI metrics that is genuinely comparable across very different teams, which is what makes it a useful benchmark rather than a vanity number.

Minute consumption bends upward, not straight

The most important shape in this benchmark is the curve, not any single point on it. CI minutes grow faster than headcount because larger organizations add branches, matrices, and pipeline frequency on top of simply having more engineers. Each new engineer does not merely add their own pushes; they add to a shared codebase whose every push now triggers more work than it did when the team was smaller. The effects multiply rather than add.

In our model consumption climbs about 4.2 times as a codebase scales past fifty engineers, so a planning assumption of linear growth materially understates the bill at scale. A finance team that projects CI cost by multiplying current per-head spend by next year's headcount will be wrong in the expensive direction, and the error grows precisely as the organization grows. The benchmark exists to make that curvature visible before it shows up on an invoice that nobody forecasted.

The mechanism behind the bend is worth naming because it points at the fix. Minutes grow super-linearly mostly because every push validates more of the repository than it changed. A larger codebase means a larger blast radius for each commit unless something deliberately constrains it. Teams that flatten the curve do so by making CI work proportional to the change rather than to the size of the repository, which is the single most effective brake on the consumption growth this chart describes.

• Modeled monthly minutes rise from about 4,200 at 5 engineers to 360,000 at 250 engineers.
• Consumption grows roughly 4.2x as a codebase scales past fifty engineers, faster than headcount.
• Linear per-head forecasting understates CI cost at scale, and the error compounds with growth.

Pull-request checks dominate the monthly burn

When monthly minutes are split by what triggered them, pull-request checks are the clear majority. They are the most frequent trigger because they run on every push to every open branch, and they are the most duplicated because the same suite reruns each time a contributor pushes a fixup. Main-branch and release builds come second, followed by scheduled nightly jobs and a long tail of manual runs and re-runs.

This distribution has a direct operational consequence. Because PR checks dominate the volume, any optimization applied there moves the total far more than the same optimization applied to nightly jobs, even though nightly jobs are often the ones teams instinctively try to trim first because they feel wasteful. The benchmark redirects attention to where the minutes actually are, which is the high-frequency, high-duplication PR path.

Caching and test impact analysis are the two highest-leverage moves on this slice precisely because they attack the per-push cost on the most-pushed path. A cache that turns a cold install into a warm restore saves a little on every nightly run and an enormous amount across thousands of PR pushes. Test impact analysis that runs only affected targets does the same. The trigger split tells the team to spend its optimization budget on the PR path first.

• Pull-request checks are about 48 percent of modeled monthly minutes, the single largest slice.
• PR checks are both the most frequent and the most duplicated trigger.
• Caching and test impact analysis on the PR path move the monthly total more than trimming nightly jobs.

Per-engineer consumption rises with org size

It is not only that bigger organizations have more engineers; each engineer also consumes more minutes as the organization grows. As matrices, cross-platform legs, and integration suites accumulate, the cost of a single engineer's typical day of pushing rises. Per-engineer minutes climb steadily across the size bands in our model, from under a thousand at the smallest band to well over fourteen hundred at the largest.

This per-engineer climb is what compounds the headcount effect and explains why the total curve bends rather than tracks straight. If per-engineer consumption were flat, the total would grow linearly with headcount. Instead both terms grow together: more engineers, each consuming more, which is a multiplicative rather than additive growth. The benchmark separates these two contributions so a team can see which is driving its own trajectory.

Practically, minutes-per-engineer is an early warning indicator that pipelines are growing faster than the team. A team can watch this single number over time and detect that its CI is becoming heavier per person before the absolute bill becomes alarming. A rising per-engineer figure usually means matrices and suites are accreting without anyone deciding they should, which is exactly the moment to introduce affected-target builds before the curve steepens further.

The bill, not the minutes, is the managed-runner win

The minutes a team consumes are largely a function of its codebase, its branching model, and its release cadence, none of which a runner change alters. What a runner change does alter is the price of each of those minutes. That distinction is the heart of the managed-runner case in this benchmark. The same monthly minutes priced at a per-minute rate about 70 percent lower turn a steep cost curve into a far flatter one without reducing how many pipelines anyone runs.

The absolute size of the win grows with org size, which is exactly where it is most needed. At twenty engineers the monthly difference between hosted and managed is modest in dollar terms. At two hundred and fifty engineers the same percentage gap is a four-figure monthly difference, because the percentage now applies to a much larger base of minutes. The runner layer pays for itself purely on consumption, and it pays more the more an organization consumes.

This is why the managed line is the durable answer to a bending consumption curve. Optimizations that reduce minutes, caching and impact analysis, help and should be done, but they require ongoing engineering attention and they hit diminishing returns. Lowering the per-minute rate is a one-time structural change that keeps paying on every minute the team will ever run, including all the new minutes the upward bend will add.

Consumption is the benchmark almost every team can use

Most CI benchmarks are stack-specific or domain-specific. Build time depends heavily on language; flake rate depends on test architecture; deployment frequency depends on release culture. Minute consumption is unusual in being broadly comparable across all of them, because nearly every team that runs CI runs it on some version of the same per-push, per-branch, per-matrix pattern that this curve describes.

With CI adoption near 76 percent of professional developers, almost every organization is consuming minutes on this curve, which makes monthly minute volume a rare apples-to-apples yardstick. A fintech team and a gaming studio may share almost nothing about their stacks, but both can ask the same question: does our consumption sit above or below the per-headcount baseline for our size band, and if above, why.

That single comparison is the simplest available signal of whether a team's pipelines are unusually heavy. A team well above the baseline for its size is doing more CI work per engineer than its peers, which is sometimes justified and sometimes pure accreted overhead. Either way, knowing it is the prerequisite to acting on it, and the benchmark turns a private suspicion that CI feels expensive into a positioned, comparable number.

The small-org band is where habits get set

The smallest bands in the benchmark consume modest absolute minutes, which makes it tempting to ignore them. That is a mistake, because the small-org band is where the pipeline shape that the org will carry for years gets established. The matrices, the trigger patterns, and the caching discipline that a five- or twenty-engineer team adopts become the defaults that the hundred-engineer version of the same org inherits, long after anyone remembers choosing them.

A small team that never set up caching is not paying much for the omission at twenty thousand minutes a month. The same omission at three hundred and sixty thousand minutes a month is a serious recurring cost, and by then it is woven through dozens of workflows that all assume the cold install. The cheapest time to fix the shape of a pipeline is while the org is small and the blast radius of a change is small; the most expensive time is after the curve has bent.

This is the argument for treating CI hygiene as a founding practice rather than a scaling project. The benchmark's per-engineer figures rise across the bands partly because overhead that was invisible when small becomes load-bearing when large. A team that bakes caching, affected-target builds, and a sane matrix into its pipelines early carries a flatter per-engineer curve into every later band, which compounds in its favor exactly as the org grows.

Forecasting the curve is the planning win

Most CI cost surprises are really forecasting failures. A team budgets next year's CI spend by scaling this year's by expected headcount growth, the curve bends, and the actual bill arrives well above the plan. The benchmark's central claim, that minutes grow about 4.2 times as a codebase scales past fifty engineers, is most useful as a forecasting correction rather than a description of the present.

Building the bend into the forecast changes the conversation with finance. Instead of being surprised twice, once by the bill and once by the realization that the model was wrong, an engineering org can present a curved projection up front, explain the mechanism, and tie it to specific levers that bend it back. A forecast that already accounts for super-linear growth is defensible; one that assumes linearity is a setup for an awkward quarter.

It also makes the value of the optimizations legible in advance. If the team can show that affected-target builds and caching flatten the per-engineer curve, then the savings can be projected against the bent baseline rather than argued for in the abstract. The benchmark gives the shape; the team supplies the levers; together they turn CI cost from a recurring surprise into a planned line that bends in a direction the org chose.

Recommendations

Forecast CI cost on the curve, not on a straight line

Stop projecting CI spend by multiplying current per-head cost by next year's headcount. Consumption grows roughly 4.2x as a codebase scales past fifty engineers, so a linear forecast understates the bill in the expensive direction precisely as the org grows. Forecast on the bending curve and budget for the curvature explicitly.

Spend the optimization budget on the pull-request path

Pull-request checks are the largest slice of monthly minutes because they are the most frequent and most duplicated trigger. Apply caching and test impact analysis there first, before trimming nightly jobs, because the same change saves far more on the high-frequency path than on a once-a-day batch.

Track minutes-per-engineer as an early-warning metric

Watch per-engineer minute consumption over time, not just the absolute bill. A rising per-engineer figure means matrices and suites are accreting faster than the team is growing, which is the leading indicator of a steepening cost curve and the right moment to introduce affected-target builds.

Make CI work proportional to the change, not the repo

The upward bend is driven largely by every push validating more of the repository than it changed. Adopt affected-target detection and incremental builds so a one-line change does not pay for a full-repository validation. This is the single most effective brake on consumption growth at scale.

Lower the per-minute rate to flatten the whole curve

Reducing minutes takes ongoing engineering effort and hits diminishing returns; lowering the price of every minute is a one-time structural change that keeps paying on every minute the team will ever run. Managed runners apply a rate about 70 percent below hosted, and the absolute saving grows with the org, which is exactly where the bending curve hurts most.

Outlook

Expect monthly minute volume to become a standard line in engineering-operations reviews through 2026, reported per size band the way headcount and cloud spend already are. As more teams instrument consumption, the per-headcount baseline in this benchmark will sharpen, and outliers, both unusually lean and unusually heavy, will become easier to spot and explain. The teams that watch the curve will forecast far more accurately than the teams that wait for the invoice.

The upward bend is structural and will not flatten on its own, because the forces that drive it, more branches, richer matrices, larger codebases, are the same forces that accompany healthy growth. What changes is whether a team lets the bend translate directly into cost. Affected-target builds and aggressive caching bend the minute curve back toward the change rather than the repository, and we expect both to move from advanced practice to default baseline over the next two years.

The most durable lever remains the per-minute rate. Reducing minutes is valuable but effortful and capped; lowering the price of every minute is a single structural decision that compounds across all future consumption, including everything the upward bend will add. For an organization staring at a steepening curve, the runner layer is the one place where a single change keeps paying as the team and the codebase grow.

Methodology

This benchmark models monthly CI minutes consumed per organization size band as run volume times average pipeline length, derived from typical run frequencies and pipeline shapes. Minute volumes, per-engineer consumption, and trigger splits are Latchkey analysis (modeled), not a primary survey, consistent with roughly 4.2x minute growth as a codebase scales past fifty engineers. Minutes are priced at the published GitHub-hosted Linux rate (0.008 per minute) to show the bill behind the volume; the managed line applies the Latchkey rate of 0.0025 per minute, a 70% reduction versus the blended hosted average. OS multiples (Linux 1x, Windows 2x, macOS 10x) are from GitHub pricing; CI adoption near 76% 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

• Stack Overflow Developer Survey
• GitHub - Octoverse
• GitHub Actions - billing & pricing
• CNCF Annual Survey

More Latchkey reports