How EmitCI's Green Scheduler shifts CI to low-carbon grid windows

Not all CI runs are equally urgent. A nightly security scan can wait two hours. A dependency update check is not blocking anyone. A scheduled report generation does not need to happen at midnight UTC. The Green Scheduler is built on this observation: defer what can be deferred, and do it transparently.

What the scheduler does

When a workflow run is queued and marked as deferrable, the Green Scheduler checks the carbon intensity forecast for the runner's grid region over the next 12 hours. If the current window is not the cleanest window in the forecast, it holds the run and re-queues it at the optimal time. If the current window is already near the minimum forecast intensity, it releases immediately.

The scheduler never delays urgent runs. Push-triggered workflows, pull request checks, and anything that would block a developer are passed through without delay. Only scheduled cron workflows , and workflows explicitly tagged as deferrable , are eligible.

The forecast model

Carbon intensity forecasts come from Electricity Maps, which provides hourly carbon intensity data and 24-hour forecasts for over 50 grid regions. We cache forecasts per region and refresh every hour. When a run is queued, we look ahead 12 hours, find the window with the lowest average intensity, and schedule the run for the start of that window.

For regions without Electricity Maps coverage, we fall back to a time-of-day heuristic built from 18 months of historical grid data: most grids are cleanest between 01:00 and 06:00 local time, when industrial demand is low and overnight wind generation peaks.

How we avoid breaking workflows

Two constraints prevent the scheduler from causing problems. First, a maximum delay cap , by default 6 hours, configurable per workflow. A run will never be held longer than the cap, regardless of forecast intensity. Second, dependency awareness , if a deferred workflow is depended on by another workflow in the same repository, the dependency is detected from the workflow YAML and the deferred run is released early.

Both constraints are visible in the dashboard. Every deferred run shows its scheduled time, the forecast intensity it is waiting for, and the estimated carbon saving versus running immediately.

Real numbers

In the first three months after enabling the Green Scheduler across our beta cohort, the average deferred run saved 1.8g CO₂ versus running at the originally scheduled time. Across all deferred runs in the cohort , roughly 40,000 per month , that is 72kg CO₂ saved monthly, for zero engineering effort and no change to build output or reliability.

The scheduler is available on the Team plan and above. If you are on Team and have not enabled it yet, it is one toggle in Settings → Green Scheduler.