Carbon-aware computing changes when, where or how work runs in response to the carbon intensity of the electricity it uses. A practical starting point is a flexible batch job: choose an eligible lower-intensity window while preserving the deadline, required output and service constraints.
The idea is simple, but a useful implementation needs more than a green-looking chart. You need an appropriate signal for the compute location, a realistic estimate of duration and a fallback when the forecast or scheduler fails.
This guide explains the basic choices and gives a worked scheduling example. Its numbers are hypothetical and are not live grid data or a claim about a particular provider.
How carbon awareness differs from energy efficiency
Energy efficiency reduces the electricity needed for a task. Carbon awareness uses information about electricity emissions to influence execution. A project can pursue both.
The Software Carbon Intensity specification distinguishes energy efficiency, hardware efficiency and carbon awareness. It also requires a declared boundary and unit of work when reporting a software carbon intensity result.
Consider a job that still uses ten kWh after rescheduling. Its energy use has not improved. An emissions estimate can change because the factor applied to that electricity changes. Keep those two effects separate.
The green software guide explains the broader principles. For changes to the computation itself, see energy-efficient code for beginners.
Three ways a system can respond
| Approach | What changes | A possible use |
|---|---|---|
| Time shifting | The start time of flexible work. | Run a non-urgent report within a lower-intensity eligible window. |
| Location shifting | The region or infrastructure used. | Choose among permitted locations with suitable capacity and data access. |
| Demand shaping | The amount or form of optional work. | Reduce an optional background activity when the signal is less favourable, while maintaining required service. |
The Green Software Foundation’s carbon-awareness learning material discusses demand shifting and shaping. Each approach needs constraints: a service’s required behaviour should remain explicit.
For a first pilot, time shifting one existing batch job is often easier to inspect than migrating work between regions. You can keep the machine and input fixed while studying the scheduling decision.
Choose a genuinely flexible workload
A workload is flexible when its timing or location can change without breaking a requirement. Identify that flexibility rather than assuming every task can wait.
| Candidate | Question to answer before a pilot |
|---|---|
| Scheduled report | When must the finished result be available? |
| Research batch analysis | Can it wait, and are the input and resources still available later? |
| Build or test job | Does delaying it block colleagues or a release? |
| Data-processing pipeline | Which downstream tasks depend on its completion? |
| Interactive request | Can any background portion move without affecting the user’s required response? |
Write down the earliest start, latest finish, expected duration, capacity requirements and retry policy. If the job cannot tolerate delay, choose another candidate.
Do not confuse “not urgent for me” with “not important to anyone.” Ask the people or systems that depend on the output.
Understand the carbon-intensity signal
Carbon intensity expresses emissions associated with a unit of electricity, commonly g CO₂e per kWh. Signals can differ in their geography, time resolution, accounting boundary and methodology.
An average signal describes an electricity mix. A marginal signal estimates the emissions associated with a change in demand under its model. Those answer different questions; identify which you use and avoid treating them as interchangeable.
For scheduling, check that the data cover where the computation happens and the interval it will occupy. A historical annual factor cannot tell you which hour is forecast to be preferable tomorrow.
| Signal detail | What to record |
|---|---|
| Location | The grid zone or supported compute region. |
| Time coverage | The interval, forecast horizon and time zone. |
| Method | Average or marginal, and the provider’s definition. |
| Units | The stated emissions unit per energy unit. |
| Freshness | When the forecast was generated or updated. |
| Limitations | Coverage gaps, model uncertainty and access restrictions. |
Keep the provider and methodology with the run record. Comparing a number from one method with a number from another can create an apparent improvement that is only an accounting difference.
Worked example: schedule a one-hour batch job
Hypothetical example: a batch job takes one hour, uses ten kWh within the stated boundary and can start from 08:00. It must finish by 12:00. Assume the energy requirement is unchanged between windows and each forecast value represents the whole run. All times use the same stated local time zone.
| Candidate window | Assumed intensity, g CO₂e/kWh | Deadline check | Illustrative operational estimate |
|---|---|---|---|
| 08:00–09:00 | 400 | Eligible | 10 × 400 = 4,000 g CO₂e |
| 10:00–11:00 | 150 | Eligible | 10 × 150 = 1,500 g CO₂e |
| 13:00–14:00 | 100 | Ineligible: finishes after 12:00 | Excluded from selection |
The 10:00 window has the lower illustrative estimate among the eligible choices. The arithmetic difference from the 08:00 case is 2,500 g, or 62.5%. The lowest number in the whole table is not a valid choice because it misses the deadline.
This is an accounting illustration under stated assumptions. If the factors are average estimates, the difference is not proof that the grid physically avoids exactly 2,500 g when you shift this job.
Real scheduling should account for the job’s energy profile over time, available capacity and duration uncertainty. A single hourly value is an approximation when the job spans changing conditions.
Protect the deadline before optimising the signal
Estimate duration from representative runs and leave room for variation, queuing and retries. The latest safe start can be earlier than “deadline minus average runtime.”
Choose a documented fallback. If the forecast is missing, stale or unsupported, the job can follow its normal reliable schedule. If the preferred window becomes unavailable, move to the next eligible choice or the fallback.
Set a limit on how often the scheduler can defer the job. A sequence of improved forecasts should not cause indefinite postponement. Monitor actual completion, not just the selected start time.
For an educational prototype, begin with a fixed set of synthetic windows and test the constraints before connecting a live data provider.
What the Carbon Aware SDK provides
The Green Software Foundation’s Carbon Aware SDK provides interfaces for building carbon-aware applications. Its documentation describes command-line and Web API use, among other integration options.
The SDK setup guide explains data-source configuration and warns that the default example uses generated random data. That sample output is not real carbon data. Configure and verify the intended source before making a scheduling or emissions claim.
Treat the SDK as part of the information workflow. Your application still needs its job constraints, execution mechanism, fallback and logging. An emissions-data response does not itself prove the job ran successfully.
Test the policy before deploying it
| Test case | Expected policy behaviour |
|---|---|
| Several eligible windows | Choose using the stated objective and consistent data. |
| Lowest-intensity window misses the deadline | Exclude it. |
| Forecast is missing or stale | Use the documented fallback. |
| Expected runtime increases | Recalculate eligibility and preserve the deadline. |
| Preferred capacity is unavailable | Choose another eligible option or fallback. |
| Job fails | Apply the retry policy without claiming the failed attempt as completed work. |
Log the inputs and decision during a small pilot. Record the forecast timestamp, candidate windows, selected time and reason for fallback. This makes the scheduling policy reviewable.
Start in observation mode if you can: record what the policy would select while the job continues on its existing schedule. That helps reveal bad assumptions before changing execution.
Measure the outcome, including overhead
Record actual runtime, energy where measurable, successful output and any additional work caused by the policy. Retries, idle resources and data movement can affect the total.
If delaying a job requires keeping dedicated hardware powered unnecessarily, include that effect in the boundary. If moving regions requires transferring a large dataset, examine the added work before claiming a net benefit.
Choose a clear comparison with the existing schedule and report uncertainty. Keep the accounting method consistent between baseline and pilot.
The green coding tools guide introduces possible measurement tools. For infrastructure context, data centre energy use explains why the supporting systems matter.
What research says about practical limits
Radovanović and colleagues describe Google’s approach to delaying flexible workloads in Carbon-Aware Computing for Datacenters. Their system combines forecasts and workload management while preserving daily capacity for the flexible work. It illustrates how operational constraints belong inside the scheduling design.
Sukprasert and colleagues’ study of the limitations of temporal and spatial workload shifting examines regions and workload characteristics including duration and deadlines. Its abstract reports that practical benefits are bounded and that simple policies can capture much of the available benefit in the studied settings.
Neither paper gives every small project a guaranteed reduction. Use the findings to frame the questions: how much flexibility exists, how variable is the relevant signal and what does the policy add to the workload?
A first-pilot checklist
Choose one bounded job. Define its deadline and successful output. Verify a suitable signal, keep the current schedule as a baseline and test fallback cases. Run a small pilot with complete decision and execution records.
Report energy and emissions estimates separately. State the method, boundary and excluded components. Use the actual result to decide whether the policy is worth maintaining.
The sustainable computing guide places this technique alongside reducing unnecessary work and making sensible hardware choices. Carbon awareness is one part of that wider approach.
Frequently asked questions
Does running at night always reduce emissions? No. Use appropriate location- and time-specific information. A time-of-day rule is not a universal carbon signal.
Does a renewable-energy claim identify the best hour? It does not automatically provide the granular grid information needed for scheduling.
Can I use a country-level annual average? It may support a coarse estimate, but it cannot rank hourly windows within that year.
Is this useful for a laptop? A flexible local task can be studied, but include waiting, charging and the limits of your energy and signal data. Start with a small, well-defined question.
A useful carbon-aware system completes the required work reliably and makes its scheduling assumptions visible. Begin with that standard, then measure what the change achieves.
Featured image: Taylor Vick on Unsplash.