Carbon-aware computing: now the default behavior
Actualizado: 2026-05-03
When Microsoft and ThoughtWorks launched the Green Software Foundation in 2021, carbon-aware computing was a niche concept that sounded nice in sustainability decks but had little operational traction. Four years later, in September 2025, the situation has shifted quietly but deeply: scheduling non-interactive workloads by grid carbon intensity has become the default behavior across much of the modern stack.
Key takeaways
- Electricity has variable carbon intensity throughout the day: the ratio between the best and worst moment can exceed 3× in many European regions — this variability is what carbon-aware computing exploits.
- By September 2025, Kepler is a graduated CNCF project, the KEDA Carbon Aware Scaler is in production, and GitHub Actions includes a
carbon-awarelabel to delay jobs up to 6 hours. - There are two very different emissions metrics: average grid intensity (easy, inflated) versus marginal intensity (harder, economically correct).
- The pattern that works best is delaying batch workloads with wide tolerance windows (training, indexing, backups) — 30 to 50% emission savings with almost no functional impact.
- The risk of environmental theater is real: flipping a checkbox does not decarbonize a company. Transparency in the numbers is the only vaccine.
What carbon-aware actually means
The core idea is simple. The electricity powering a data center does not have a constant carbon footprint. At 2pm on a sunny day in southern Spain, the grid is full of solar and intensity can be around 80 grams of CO₂ per kilowatt-hour. By 8pm on the same day, as the sun sets and gas combined-cycle plants ramp up, intensity rises to 220 grams. The ratio between the best and worst times of day can exceed 3 in many European regions.
Carbon-aware computing exploits this variability to run time-flexible workloads — model training, CI builds, backups, or batch data jobs — in low-intensity windows. If a task can wait four hours without consequence and intensity drops by half in those four hours, running it in the clean window cuts emissions proportionally.
There is also a spatial version of the same idea. If your workload can run in any of three cloud regions and one of them currently has a much cleaner grid, running there has the same effect. Azure has offered an electrical-load optimization service since 2023 along those lines; Google Cloud publishes Carbon Free Energy Scores for its regions; AWS publishes intensity data but has not integrated automatic policies.
What changed in two years
In 2023 the tooling ecosystem was a set of disconnected experimental projects. By September 2025 the landscape is much more integrated:
- Kepler is a graduated CNCF project with production deployments at Spotify, Red Hat, and several financial institutions.
- The KEDA Carbon Aware Scaler, launched in 2024, scales Kubernetes workloads automatically based on carbon intensity.
- GitHub Actions, since June 2025, includes a
carbon-awarelabel on hosted runners that delays scheduled jobs by up to 6 hours if the grid is dirty. GitLab has announced equivalent support for October. - Azure Functions transparently redistributes background tasks across regions without user configuration.
The last point is a symptom of maturity: carbon awareness stops being a premium option and becomes an internal provider tuning.
The hard part: measuring well
The fundamental problem with carbon-aware computing is not implementing it but measuring whether it actually reduces emissions. There are two measurement approaches that give very different answers.
The first is average grid intensity, the number published by bodies like Red Electrica in Spain or ENTSO-E. It is easy to obtain but conceptually questionable: if everyone runs workloads during sunny hours, the grid no longer has excess renewables then and the window disappears.
The second is marginal intensity, which measures which power plant starts or stops in response to a demand change. This is the economically correct metric but much harder to compute. WattTime publishes it for U.S. markets and ElectricityMaps started offering it in 2024 for Europe. The difference between average and marginal can be twofold: an hour that looks clean by average intensity can be dirty marginally if any extra kilowatt-hour is covered by gas combined cycle.
For a team doing carbon-aware computing with intellectual integrity, the recommendation is to use marginal intensity where available and to be transparent about which metric is being reported. Emission reductions reported via average intensity tend to be inflated.
Patterns that work and patterns that do not
The pattern that works best is delaying batch workloads with wide tolerance windows:
- AI model training that can start any time in the next 4 hours
- Search indexing that can run any day of the week
- Incremental backups that tolerate hours of delay
For these workloads the emission saving can be 30 to 50% with almost no functional impact.
The pattern that does not work is forcing interactive workloads to follow the grid. A web server cannot wait 4 hours for intensity to drop because neither will its users. For service workloads the right lever is not temporal carbon awareness but absolute energy efficiency: profile, optimize consumption per request, use architectures that scale to zero when idle.
An interesting intermediate pattern is peak smoothing: if your traffic has predictable daily peaks and you can precompute certain results overnight, moving that precomputation to low-intensity hours has a double benefit: it relieves tomorrow’s peak and cuts the precomputation’s emissions. This works well for recommender systems, log analysis, and scheduled report generation.
Incoming regulatory pressure
A factor few teams are watching but will push hard over the next two years is European regulation. The revised 2023 Energy Efficiency Directive requires data-center operators above 500 kilowatts to report consumption, energy mix, and emissions. The next iteration, expected for 2026, will add effective-use metrics, not only installed capacity.
In practice this means cloud providers will start exposing more detailed consumption and emission metrics attributable to each customer. For a team planning to report carbon footprint for fiscal year 2026, start collecting these metrics now and testing auditable carbon-aware patterns.
The risk of environmental theater
A real risk of carbon-aware computing is that it becomes theater. A team announces its CI pipeline is carbon aware, earns a green badge in corporate documentation, and the real emission reduction is below 5% because most jobs are not delayable. Marketing outpaces substance.
The countermeasure is transparency in the numbers. An honest carbon-aware report includes:
- What proportion of total workloads was effectively rescheduled
- The energy-weighted intensity reduction achieved
- The measurement method used
If those three items are not reported, the published figure is probably inflated. Auditors already know this.
My take
Carbon-aware computing has gone from marketing concept to built-in platform capability in a short time. That is good news for the industry’s operational sustainability but demands more rigor from teams. Flipping a checkbox on a CI runner is not decarbonizing a company, and treating it as such confuses sustainability leaders and dilutes the credibility of serious initiatives.
My practical recommendation is to classify workloads by time sensitivity and apply the right tool to each class:
- Batch workloads with wide windows: enable carbon-aware scheduling and measure the result with marginal intensity.
- Interactive workloads: profile, optimize, and scale to zero when possible.
- Hybrid workloads: split the precomputable part to clean hours and keep the online part efficient.
- Report each separately.
What I find most interesting about this transition is that it is one of the rare software optimizations that combine real environmental benefit with cost savings in many cases. Cleaner electricity is usually cheaper in deregulated markets because renewable surplus is also when wholesale prices drop. A team that schedules well reduces both bill and emissions with the same lever. That alignment of economy and ecology is rare and worth exploiting before it disappears under market saturation.
