The State of CI/CD 2026

How modern engineering teams build, test, and ship, and what their pipelines actually cost.

Executive summary

Continuous integration is no longer a competitive edge, it is table stakes. The overwhelming majority of professional teams now run automated pipelines on every push, and CI has quietly become one of the largest line items in an engineering organization's tooling and compute budget. The question for 2026 is not whether to run CI, but how to keep it fast, reliable, and affordable as the codebase and the team grow.

The data shows a widening gap between two kinds of teams. The first treats CI as managed infrastructure: they invest in caching, sharding, right-sized runners, and automated recovery, and their pipelines stay fast and cheap as they scale. The second is still firefighting: build times that grow faster than headcount, flaky tests that tax every merge, and runner bills that balloon non-linearly once macOS, Windows, and matrix jobs enter the picture.

This report quantifies where the time and the money go. We look at how pipeline length scales with test count, how much of a typical CI minute is actually useful work, what cross-platform runners really cost, and where the highest-return optimizations sit. The throughline is that most waste in CI is mechanical rather than fundamental, which means it is addressable without rewriting a single test.

Three numbers frame the year. Roughly three quarters of professional developers report using CI/CD in their daily workflow. CI minute consumption grows about four times faster than headcount once a team passes the fifty-engineer mark, driven by larger test suites, more branches, and richer matrices. And a macOS CI minute on hosted runners costs about ten times a Linux minute, which is why a small slice of cross-platform jobs can dominate a bill.

The good news for engineering leaders is that the levers are well understood and cheap relative to their payoff. Caching, test impact analysis, fail-fast ordering, runner right-sizing, and self-healing for transient failures are pipeline hygiene, not moonshots. The teams that adopt them turn CI from a tax into an advantage, and they do it without adding a platform team they do not yet have.

CI on every push is universal; the frontier is keeping it fast

Most teams reached 'CI on every push' years ago. Adoption now sits near the ceiling for organizations of any real size, and the few holdouts are mostly very small teams or legacy environments. The interesting story in 2026 is not how often pipelines run, it is how long they take and what that latency does to the rest of the development loop.

Median pipeline wall-clock time grows roughly with the square root of test count when teams do nothing special, and closer to linearly once a suite outgrows a single runner. A service that took four minutes to validate at launch routinely takes fifteen to twenty-five minutes two years later, not because the tests got slower individually, but because there are far more of them and they run in sequence. Pipeline time is the single most visible CI metric to developers, and it sets the tempo for how often they are willing to push.

The teams that stay fast treat pipeline latency as a budget they defend. They cap it explicitly, they alert when it regresses, and they reach for caching, sharding, and test impact analysis before they reach for bigger runners. Throwing more cores at a sequential pipeline buys a little headroom; restructuring the pipeline to do less work and do it in parallel buys an order of magnitude.

Flaky tests are the most underpriced cost in CI

A flake rate of just two percent of builds sounds harmless until you do the arithmetic. At a few wasted minutes per re-run, plus the far more expensive engineer context switch when a green change comes back red for no reason, a two percent flake rate compounds into thousands of dollars and dozens of lost engineering hours per month for a mid-size team.

The critical insight is that most of these failures were never really broken. They are transient or mechanical: a network blip pulling a dependency, a registry timeout, an out-of-memory kill on an undersized runner, a race that only shows up under load. They pass on a clean retry. The test code is fine; the environment hiccuped. That is why quarantining or rewriting tests is the wrong first response for the bulk of flakes.

Self-healing runners attack this directly. When a step fails on a known-transient signal, 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 developer never loses focus, and the minutes spent are recovery minutes rather than wasted ones. The chart below shows how a meaningful slice of a typical billed CI minute is spent on exactly this kind of avoidable re-run.

• A 2% flake rate on a team merging 200 times a week means roughly 4 spurious red builds a week, each triggering a re-run and a context switch.
• Transient categories (network, registry, OOM, cold cache) dominate; genuinely nondeterministic test logic is the minority.
• Retrying on a fresh environment fixes the mechanical majority without touching test code.

macOS and Windows quietly drive half the bill

On hosted runners a macOS minute costs about ten times a Linux minute, and a Windows minute about twice. Those multipliers are not a rounding error in a cross-platform matrix, they are the dominant term. Teams that build for Apple platforms or ship Windows binaries routinely find that a small fraction of their total minutes is responsible for the majority of their CI spend.

The pattern is almost always the same when teams audit their bills. The Linux legs of the matrix are cheap and fast. The macOS and Windows legs are slow and expensive, and they are frequently running work that did not need that operating system at all: linting, unit tests, and dependency resolution that would pass identically on Linux. The expensive runners end up doing cheap work.

The fix is to push the heavy, OS-agnostic work onto Linux and reserve macOS and Windows for the genuinely platform-specific legs: signing, packaging, and platform UI tests. This single reshaping often cuts a cross-platform bill by a third or more, with no loss of coverage, because the platform-specific surface is much smaller than the matrix that grew up around it.

Build time grows faster than the team

CI minute consumption does not scale linearly with headcount, it scales with everything headcount produces: more services, more branches, more tests, more matrix dimensions, and more frequent merges. Our modeling puts the growth at roughly four times the rate of engineer count once a team passes about fifty people, and the curve steepens rather than flattens as the codebase matures.

This is why CI cost surprises tend to arrive suddenly. A team that was comfortable at twenty engineers crosses a threshold where the monorepo is large enough that every push rebuilds and retests far more than it changed. Without test impact analysis, a one-line change still pays for a full validation, and the bill grows with the codebase rather than with the diff.

The teams that break this curve do two things. They make CI do work proportional to the change rather than proportional to the repository, using affected-target detection and incremental builds. And they cache aggressively so that unchanged dependencies and build outputs are restored rather than recomputed on every run. Both move the cost driver from 'size of the codebase' back to 'size of the change'.

The managed-runner inflection point

Self-hosting runners looks cheaper on a spreadsheet. You compare a raw instance price to a hosted per-minute rate and conclude you can run your own fleet for less. That comparison almost always omits the two costs that actually decide the question: idle compute and engineering time.

Idle compute is the gap between capacity and demand. CI load is spiky, so a self-hosted fleet sized for peak sits mostly idle off-peak, and a fleet sized for the average starves jobs during peak. Either way you pay, in money or in developer wait time. Engineering time is the patching, scaling, image maintenance, security hardening, and cleanup that a runner fleet demands continuously, work that competes directly with shipping product.

Managed runners capture most of the per-minute compute savings of self-hosting while removing the idle and the operations entirely. That is why the break-even math increasingly favors managed for any team without a dedicated platform group, and often even for those that have one. The relevant comparison is not instance price versus hosted price, it is total cost of ownership including the team time that self-hosting quietly consumes.

• Idle capacity off-peak is a real, recurring cost that raw instance pricing hides.
• Patching, scaling, and image maintenance are continuous engineering work, not a one-time setup.
• Managed runners price close to self-hosted compute while removing idle and ops; Latchkey targets roughly 69% below GitHub-hosted rates.

Caching is the highest-ROI lever most teams underuse

Dependency installation and build steps that recompute unchanged work are the quiet majority of wasted CI minutes. In a typical web-application pipeline, a sizable share of every billed minute goes to installing dependencies that did not change since the last run and rebuilding artifacts that are bit-for-bit identical to yesterday's.

Caching is conceptually simple and operationally finicky, which is why so many teams do it badly or not at all. A cache that is keyed too loosely serves stale content; a cache that is keyed too tightly almost never hits. The teams that win treat cache keys as a first-class part of the pipeline, scoped to the lockfile and toolchain version, and they measure hit rates the way they measure test coverage.

When caching works, the effect is immediate and compounding. Cold installs that took minutes drop to seconds, build steps restore instead of recompute, and the saved minutes show up directly on the next invoice. Of all the optimizations in this report, dependency and build caching has the best ratio of payoff to effort, and it requires no change to application code.

Security and isolation moved from nice-to-have to default

CI runs with access to source code, package registries, cloud credentials, and deploy keys, which makes it one of the most valuable targets in an engineering organization. Over the last few years the industry has moved decisively from long-lived secrets and shared runners toward short-lived credentials and per-job isolation, and in 2026 that posture is the expectation rather than the exception.

The concrete shifts are short-lived OIDC tokens in place of stored cloud keys, least-privilege scoping for the credentials a job actually needs, and ephemeral, single-use runner environments so that one job cannot observe or poison the next. Each of these closes a class of incident that used to be common: a leaked static key, a poisoned cache, a compromised dependency that persists across runs.

Isolation also intersects with reliability and cost. A clean, single-use environment per job eliminates an entire category of flaky failures caused by state bleeding between runs, and it makes the platform's behavior predictable. Managed runners that provision a fresh environment per job deliver this isolation by default, which is part of why the security and reliability stories increasingly point at the same architecture.

What the fastest teams do differently

The top quartile of teams on delivery metrics do not have a secret tool. They share a short, unglamorous set of habits, applied consistently. None of these habits require rewriting the application, and most are configuration rather than code. They are pipeline hygiene plus the right runner layer underneath.

These teams also instrument CI as a product surface. They track pipeline duration, queue time, flake rate, and cost per merge over time, and they treat regressions in those numbers as bugs. Because they can see the curve, they intervene before a slow pipeline becomes a cultural tax that discourages people from pushing small changes often.

• Aggressive dependency and build caching, with monitored hit rates.
• Test sharding with impact analysis so work scales with the change, not the repo.
• Fail-fast ordering and cancel-in-progress concurrency to stop wasting minutes on doomed runs.
• Right-sized runners and a Linux-first matrix, with macOS and Windows reserved for platform-specific legs.
• Automated recovery for transient failures so mechanical flakes never reach a human.

Recommendations

Right-size runners and shift the matrix to Linux

Audit which jobs actually need macOS or Windows and move everything else to Linux. Reserve the expensive operating systems for signing, packaging, and platform UI tests. Match runner size to the job rather than defaulting everything to the largest tier. This is usually the fastest path to a materially lower bill with no loss of coverage.

Cache dependencies and build outputs, and measure hit rate

Treat cache keys as a first-class part of the pipeline, scoped to lockfiles and toolchain versions. Then watch the hit rate the way you watch test coverage. A cache nobody measures is a cache that silently stops working.

Make CI work proportional to the change

Adopt test impact analysis and affected-target builds so a one-line change does not pay for a full-repository validation. This is the single most effective brake on the cost curve as a codebase grows.

Auto-heal transient failures instead of quarantining tests

Most flakes are mechanical and pass on a clean retry. Retrying on a fresh environment removes the majority of the flaky tax without touching test code, and it keeps red checks caused by infrastructure from ever reaching a developer.

Instrument the four DORA metrics plus cost per merge

You cannot defend a pipeline budget you cannot see. Track deployment frequency, lead time, change failure rate, and time to restore, and add CI cost per merge so the finance and engineering views agree on the same number.

Outlook

Expect the gap between managed-CI teams and firefighting teams to widen through 2026 and into 2027. The optimizations in this report compound: a team that caches, shards, right-sizes, and auto-heals does not just spend less, it ships faster, which lets it merge more often, which makes every one of those optimizations matter more. The teams that do none of these things feel the opposite compounding as their codebase grows.

The architectural direction is clear. Short-lived credentials, ephemeral per-job environments, and managed runners that deliver isolation, elasticity, and self-healing by default are converging into a single expected baseline. The security story, the reliability story, and the cost story increasingly point at the same setup, which is what makes it durable rather than a passing trend.

For most teams the practical takeaway is that CI does not need a heroic project to fix. It needs a budget, a small set of well-understood habits, and a runner layer that removes the mechanical waste automatically. The organizations that internalize that will spend the next two years treating CI as an advantage while their peers keep paying a tax they could have removed.

Methodology

This report synthesizes publicly available industry data, including developer surveys, the DORA State of DevOps research, and published cloud and CI runner pricing, with Latchkey's own analysis of CI/CD runner economics across managed GitHub Actions workloads. Where a figure is attributed to a named source it reflects that source. Where a figure is labeled modeled it is an illustrative estimate derived from public pricing and representative pipeline shapes rather than a primary survey, and it is 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

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

More Latchkey reports