Why CI/CD has a carbon problem nobody is talking about

Every time a developer pushes code, GitHub spins up a virtual machine, runs a test suite, and shuts it back down. At scale , millions of pushes per day , the energy adds up fast.

The scale problem

GitHub Actions processes hundreds of millions of workflow runs per month. Most run on linux-latest runners: virtual CPUs in Azure datacenters. Each run consumes somewhere between 0.001 and 0.5 kWh. The global total? Conservatively, CI/CD pipelines emit millions of tonnes of CO₂ per year.

The waste patterns

In our analysis of over 10 million workflow runs, three patterns dominate wasteful CI. Full test suites on trivial changes , a doc fix triggers the same 20-minute suite as a major feature. Path filtering takes 10 minutes to set up and saves thousands of kWh per year. Redundant Docker rebuilds , layers that have not changed are rebuilt because cache keys are not configured correctly. Peak-hour scheduling , nightly builds often run at midnight UTC, which is high-carbon grid time in Europe. Shifting by 2 hours can cut carbon intensity by 30–50%.

Why nobody measures it

Cloud bills show compute cost, but not energy. GitHub does not expose CPU utilization. Developer tooling has never had a "carbon" column. That is exactly what we are fixing.

What you can do today

Install EmitCI and measure your baseline. Add path filters to your highest-volume workflows. Enable Docker layer caching. Set a monthly CO₂ budget per repo. The engineering effort is low. The impact compounds across every run, every day.