Updated: 2026-07-07

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, and that variability is what carbon-aware computing exploits.

  • As of September 2025, Kepler is still a CNCF Sandbox project (not graduated), KEDA’s carbon-aware operator exists only as an open proposal, and third-party services like CarbonRunner route CI jobs to lower-carbon regions.

  • 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), with 30 to 50% emission savings and 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, 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 cleaner grid, running there has the same effect. None of the big three fully automate this yet without the team asking for it: Azure Carbon Optimization[1], in public preview since August 2024, is a dashboard for deciding with data, not a silent adjustment; Google Cloud publishes a carbon-free-energy percentage (CFE %) by region and hour; AWS publishes its own intensity data, but without an equivalent automatic shifting policy.

What changed in two years

In 2023 the tooling ecosystem was a set of disconnected experimental projects. The Green Software Foundation’s Carbon Aware SDK[2] was useful but required heavy manual integration. Kepler, the energy-consumption exporter for Kubernetes workloads, had just entered CNCF Sandbox.

By September 2025 the pieces fit together better, though with nuances worth stating plainly rather than taking each vendor’s marketing framing at face value:

  • Kepler is still in CNCF Sandbox[3], accepted in May 2023, not yet graduated. In 2026 it went through a re-architecture to stop depending on the broad eBPF privileges that made it hard to deploy in production clusters with strict security policies.

  • Microsoft maintains a carbon-aware KEDA operator[4] that throttles autoscaling based on grid intensity without touching application code, but the proposal to integrate it into KEDA’s core was still open and unresolved as of mid-2026.

  • GitHub Actions does not natively offer a carbon-aware label; what exists are third-party services like CarbonRunner[5], which swap the usual runs-on for runners that route work to lower-intensity regions in real time.

  • Azure documents how to shift workloads in time and region with the Carbon Aware SDK, and since August 2024 adds Azure Carbon Optimization as a measurement dashboard; neither piece acts on its own yet.

The real symptom of maturity is not that carbon awareness now runs on autopilot, but that it no longer requires hand-built tooling: there is now a concrete piece of infrastructure, with a public repository and a proper name, for nearly every layer of the problem. Turning it on remains an explicit team decision, not a silent adjustment by the provider.

Renewable energy investment growth chart, the source of grid variability that makes carbon-aware computing possible by scheduling workloads in windows of high solar and wind generationRenewable energy investment growth chart, the source of grid variability that makes carbon-aware computing possible by scheduling workloads in windows of high solar and wind generation

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. It is the economically correct metric, but much harder to compute. WattTime publishes a real-time marginal signal (MOER)[6] for North American markets. Electricity Maps researched a machine-learning marginal signal for Europe starting in 2024 and ended up pulling it from their product[7]: their own team documented that the underlying value is not observable or verifiable against ground truth, so the result is a statistical model, not a measurement. That withdrawal is itself the lesson: marginal intensity is conceptually better, but building a reliable, auditable signal remains unsolved, even for one of the sector’s most sophisticated providers. 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 an auditable source exists, today mostly WattTime in North America, and be explicit about which metric is being reported when it does not. Emission reductions reported via average intensity without that caveat 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[8] requires data-center operators with at least 500 kilowatts of installed IT power to report consumption, energy mix, and emissions to an EU database (the first report, covering 2023, was due 15 September 2024; from 2025 the annual deadline is 15 May). Several member states lowered that threshold when transposing the directive: Germany to 300 kW, France to 100 kW.

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 stopped being a niche experiment and become a capability available by default in much of the modern platform, though turning it on remains an explicit team decision rather than an invisible adjustment by the provider. 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.

This article is also available in Spanish: Cómputo consciente de carbono: ya es el comportamiento por defecto.

Sources

  1. Azure Carbon Optimization
  2. Green Software Foundation’s Carbon Aware SDK
  3. CNCF Sandbox
  4. carbon-aware KEDA operator
  5. CarbonRunner
  6. WattTime publishes a real-time marginal signal (MOER)
  7. Electricity Maps researched a machine-learning marginal signal for Europe starting in 2024 and ended up pulling it from their product
  8. revised 2023 Energy Efficiency Directive