The 2026 CI Carbon Footprint Report
What continuous integration actually emits, and how much of it is idle waste that ships nothing.
Executive summary
CI is one of the few workloads an engineering organization runs thousands of times a day, every day, mostly unattended. That makes it a meaningful and almost entirely overlooked source of compute emissions. Each push spins up runners, pulls images, installs dependencies, and burns CPU on work that is frequently redundant with the run before it, and because no human watches any individual run, the aggregate cost stays invisible until someone adds it up.
This report models the carbon cost of a CI pipeline using published cloud carbon-intensity factors, then decomposes it phase by phase. The uncomfortable finding is how much of the footprint is not useful test or build work at all. It is idle runners waiting for jobs, uncached dependency installs repeating identical downloads, and re-runs triggered by flaky failures that pass on a clean retry. Roughly two fifths of the modeled footprint produces nothing that ships.
The reassuring finding is that the same moves that make CI faster and cheaper also make it greener, because the wasted compute is the same in all three accountings. Warm pools cut the idle boot waste, caching kills redundant downloads, and self-healing runners eliminate the re-run emissions from transient failures. Right-sizing the runner to the job removes the rest. None of these is a sustainability initiative with its own budget; they are ordinary CI hygiene that happens to lower emissions as a side effect.
Operating-system placement turns out to be the largest single carbon lever, mirroring its role in cost. A macOS runner-hour carries far heavier compute weight than a Linux one, so the same OS multiplier that drives the bill drives the emissions. A small slice of cross-platform jobs running OS-agnostic work on premium operating systems can dominate both the carbon and the cost of a pipeline, and moving that work to Linux fixes both at once.
The practical conclusion is that greener CI does not require a trade-off against speed or spend, and it does not require new tooling bought specifically for sustainability. It requires removing the idle, the redundant, and the flaky from the pipeline, which a team should want to do regardless of carbon. A managed warm pool that lands roughly 69 percent below hosted cost is, by construction, also a lower-carbon pipeline, because the compute it removes is precisely the compute that was producing emissions without producing output.
Grams of CO2e per runner-hour, scaled by the relative compute weight of each OS. · Source: Latchkey analysis (modeled)
Modeled split of CI compute CO2e for a typical web-app pipeline. · Source: Latchkey analysis (modeled)
Email me the report
The full report is right here on this page, free. Want the link in your inbox to read later or share, plus new Latchkey reports as they drop? Drop your email and we will send it over.
Sent! Check your inbox for the report link.
No spam. Unsubscribe anytime.
Idle and redundant work is nearly half the footprint
Once you separate useful test and build compute from everything else, roughly two fifths of CI emissions come from idle runners, redundant dependency installs, and flaky re-runs. In the modeled split, useful work is 57 percent and the remaining 43 percent is idle-and-boot, redundant installs, and flaky re-runs combined. None of that 43 percent ships a feature, and all of it is addressable without touching application code.
The categories are mechanical, not fundamental. Idle-and-boot is the compute a runner burns provisioning and waiting before it does anything useful. Redundant installs are identical downloads repeated because the cache did not persist. Flaky re-runs are full pipeline executions spent confirming a result the first run would have produced without a transient hiccup. Each is a structural inefficiency in how the pipeline is operated, not a cost of the work itself.
Because the waste is mechanical, it is removable with mechanical fixes: warm pools for the idle, caches for the redundant installs, self-healing for the flaky re-runs, and right-sizing for the rest. The reduction-levers chart shows how much each removes when applied independently, and the levers stack, which is why the combined effect reaches well over half the footprint even though no single lever does.
- Modeled split: 57% useful work, 19% idle-and-boot, 15% redundant installs, 9% flaky re-runs.
- The 43% of non-useful emissions is mechanical and removable without touching application code.
- Warm pools, caching, self-heal, and right-sizing each target a different slice and stack together.
macOS is the carbon hot spot, not just the cost one
macOS runner-hours carry far heavier compute weight than Linux, so the same OS multiplier that drives cost also drives emissions. With Linux at 1x, Windows at 2x, and macOS at 10x relative compute weight, a macOS runner-hour models at roughly ten times the carbon of a Linux one, which is why the per-OS chart is so lopsided.
The pattern teams find when they audit is almost always the same as on the cost side. The Linux legs of a matrix are light and fast. The macOS legs are heavy and frequently running work that did not need macOS at all: linting, unit tests, and dependency resolution that would pass identically on Linux. The expensive, high-carbon runner ends up doing cheap, OS-agnostic work.
Moving the heavy build and test legs to Linux and reserving macOS for the jobs that truly need it, signing, packaging, and platform UI tests, cuts both the bill and the footprint at once. This single reshaping often removes a large share of a cross-platform pipeline's emissions with no loss of coverage, because the genuinely platform-specific surface is much smaller than the matrix that grew up around it.
- Relative compute weight: Linux 1x, Windows 2x, macOS 10x.
- A macOS runner-hour models at roughly ten times the carbon of a Linux one.
- Reserve premium operating systems for signing, packaging, and platform tests; run the rest on Linux.
Warm pools cut idle boot waste
Cold provisioning means every job pays a boot-and-image penalty in compute it never uses for the actual work. The instance starts, the operating system initializes, the base image is pulled, and the runner registers, all burning CPU and drawing power before the first useful instruction runs. On a pipeline that runs thousands of times a day, that boot tax is paid thousands of times a day.
A warm pool amortizes that across many jobs. Instead of every job cold-booting its own instance, a small pool of pre-warmed runners is kept ready and reused, so the idle-and-boot slice shrinks dramatically. In the levers model, the warm pool is the single largest independent reduction at 22 percent, because boot waste is paid on every job and a warm pool removes it from nearly all of them.
There is a balance to strike, because a warm pool that is too large becomes its own idle waste, sitting powered on with no jobs to run. The carbon-optimal pool tracks demand: warm enough to absorb the common load without cold starts, lean enough not to idle. A managed warm pool that auto-scales to the workload captures the reduction without recreating idle waste in a different place.
Modeled share of CI compute emissions removed by each lever, applied independently. · Source: Latchkey analysis (modeled)
Caching removes repeated identical downloads
Uncached pipelines re-download and rebuild the same dependencies on every run. The same package set, byte for byte identical to yesterday's, is fetched across the network and unpacked again, and the same unchanged code is recompiled into the same artifact. All of that is compute and network transfer spent reproducing a result that already existed.
Effective dependency and build caching eliminates that redundant compute and network transfer. A cache hit restores the prior result instead of recomputing it, which removes both the CPU of the rebuild and the energy of the data transfer. In the model, caching removes 18 percent of the footprint, and it is one of the cleanest wins because the cached run is simultaneously the faster and the cheaper run.
Caching is also the lever with the least downside. It changes no application behavior, introduces no risk beyond a stale key that content-addressing prevents, and pays out on every job. For a sustainability program looking for a first move that does not trade against velocity or spend, the cache is the obvious place to start, because the greener run is strictly better on every axis.
Self-healing removes the emissions of avoidable re-runs
Flaky failures are a carbon cost most teams never attribute. A transient network blip, a registry timeout, or an out-of-memory kill turns a green run red, a developer hits re-run, and the entire pipeline executes again, drawing the same power to confirm a result the first run would have produced without the hiccup. The re-run is pure waste: it ships nothing the first run did not.
In the model, flaky-failure re-runs are 9 percent of the footprint, and self-healing removes most of them by retrying the known-transient failure on a fresh environment automatically, before a human ever triggers a full re-run. The recovery is targeted at the failed step rather than re-executing the whole pipeline, so even the recovery costs far less compute than a manual re-run does.
This lever also illustrates why the carbon and reliability stories point at the same architecture. A platform that auto-heals transient failures emits less because it re-runs less, and it is also more reliable because red checks caused by infrastructure never reach a developer. The emissions saving is a side effect of a reliability feature, which is the recurring shape of greener CI.
Right-sizing the runner removes carbon the job never used
A runner sized larger than the job needs draws power for cores that sit idle. Defaulting every job to a large tier feels safe but means a lint job that needs one core is powering eight, and the seven idle cores are emissions with no output. Oversizing is the quiet, per-job version of the same idle waste a warm pool fixes at the fleet level.
Right-sizing matches the runner to the job so the compute drawn tracks the compute used. In the model this removes 16 percent of the footprint, second only to the warm pool, because oversizing is so common: teams pick a tier once and apply it everywhere rather than per job, and the mismatch compounds across every run.
The carbon-optimal size is also frequently the cost-optimal one, with the same caveat about parallelism from the build-time analysis. Past the point where a job can use more cores, extra cores add carbon and cost without adding speed. A managed layer that right-sizes per job captures the correct size automatically instead of leaving every job on a single oversized default.
Greener CI and cheaper CI are the same project
Every lever that lowers emissions here also lowers cost: less idle compute, fewer re-runs, fewer redundant installs, smaller runners. This is not a coincidence; it is structural. Carbon and cost both scale with compute drawn, so any compute you remove that was not producing output reduces both at the same time and by the same mechanism.
That alignment is what makes greener CI achievable without a separate budget line or a trade-off against velocity. A team does not have to choose between shipping fast and shipping green, because the wasted compute it removes to go green is the same wasted compute that was slowing the pipeline and inflating the invoice. The greener pipeline is the faster, cheaper pipeline.
A managed warm pool that lands roughly 70% below hosted cost is, by construction, also a lower-carbon pipeline, because the saving comes from removing idle, redundant, and flaky compute rather than from a cheaper energy source. The annual-emissions chart shows the size of the prize: a greened 200-engineer estate models at well under half the carbon of the unoptimized one, with the same output.
Kilograms of CO2e per year from CI compute, by engineering headcount. · Source: Latchkey analysis (modeled)
Recommendations
Audit OS placement first; it is the largest single lever
A macOS runner-hour models at roughly ten times the carbon of a Linux one. Move linting, unit tests, and dependency install to Linux and reserve macOS and Windows for signing, packaging, and platform-specific tests. This cuts both the footprint and the bill of a cross-platform pipeline with no loss of coverage.
Run a demand-tracking warm pool instead of cold-booting every job
Cold provisioning pays a boot-and-image carbon tax on every job. A warm pool that auto-scales to demand removes most of it and is the single largest independent reduction in the model. Keep the pool lean so it does not become idle waste in a different place.
Cache dependencies and build outputs to kill redundant compute
Uncached pipelines re-download and rebuild identical work on every run. Effective caching removes that redundant compute and network transfer, and because the cached run is also faster and cheaper, it is the cleanest greener-CI win with no trade-off against velocity.
Auto-heal transient failures so re-runs do not re-emit
A flaky re-run draws the full pipeline power to confirm a result the first run already produced. Self-healing retries the transient failure on a fresh environment automatically, removing most re-run emissions and improving perceived reliability at the same time.
Right-size runners per job rather than defaulting to a large tier
A runner larger than the job needs draws power for idle cores. Match the runner to the job so compute drawn tracks compute used, and stop sharding past the point where extra cores add carbon and cost without adding speed.
Outlook
Through 2026 and into 2027, software carbon accounting moves from a niche concern to a reported metric, and CI compute will increasingly show up in those reports because it is large, continuous, and until now unmeasured. Teams that have already removed the idle, redundant, and flaky compute from their pipelines will find they have a green CI story almost by accident, because the hygiene they adopted for speed and cost also lowered their footprint.
The architectural direction reinforces the alignment. Warm pools, persistent caches, per-job right-sizing, and self-healing are converging into a managed baseline that lowers emissions, cost, and wall-clock together, because all three scale with the same wasted compute. As that baseline spreads, the question shifts from whether greener CI is worth a trade-off to why a team would run the wasteful version at all when the efficient one is strictly better.
For most teams the practical takeaway is that greener CI needs no separate budget and no sustainability tooling bought for its own sake. It needs the same caching, warm capacity, right-sizing, and self-healing that make CI fast and cheap. The organizations that internalize that will report a falling CI footprint as a side effect of running a well-operated pipeline, while their peers keep emitting for idle, redundant, and flaky compute they could have removed.
Methodology
This report models CI compute emissions by applying published cloud carbon-intensity factors to modeled runner-hours, with per-OS figures scaled by the relative compute weight of each platform (Linux 1x, Windows 2x, macOS 10x). Emission splits, lever reductions, and annual totals are illustrative Latchkey estimates derived from typical pipeline shapes, not measured datacenter telemetry; the managed cost reference of 70% below hosted is likewise modeled. 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.