TL;DR — Carbon-aware scheduling is not one magic number. The savings you get are the product of a handful of tradeoffs, and pulling any lever tugs the others. Savings scale with SLACK (more deadline room → more clean windows to hit; zero slack → zero savings) and with CI variance (flat grid → nothing to gain). A per-hour capacity cap
Mmakes jobs contend, pushing some off the greenest hour. Deferring costs latency / freshness. Your headline number is on an average-CI basis — it can look different on a marginal basis. Cheap clean power can trigger a rebound (more load). And you can shift a job in time (temporal) or in space (spatial — move it to a cleaner region), each with its own cost. This article makes every lever concrete, with a sensitivity function that shows savings as a function of slack and ofM.
1. Simple explanation (plain English + analogy)
People hear "carbon-aware scheduling saves 80%" and think it is a free switch. It is not. It is a set of knobs that fight each other, and the real savings depend on your specific job and grid.
Think of it as five dials:
- Slack — how much spare time the job has before its deadline.
- CI variance — how much the grid's cleanliness actually swings.
- Capacity — how many jobs can share the greenest hours.
- Latency — how much you are willing to delay the result.
- Accounting honesty — average vs marginal, and rebound.
Analogy — flying on cheap days. Flights are cheaper on some days than others (that is CI variance). If your trip can move within a wide date range you can grab the cheapest day (slack). But if everyone wants that cheap Tuesday, the cheap seats sell out and you settle for a pricier day (capacity contention). Waiting for the cheap day also means you travel later (latency). And the "average fare this week" you quoted might not match what your specific seat actually cost (average vs marginal). Same trip — the savings depend on all five dials, not one.
The honest headline: no slack, no savings. Flat grid, no savings. Tight cap, less savings. Carbon-aware scheduling is powerful exactly where a load is flexible and the grid is variable — and near-useless everywhere else.
2. Diagram (ASCII)
THE FIVE LEVERS OF CARBON-AWARE SCHEDULING (all coupled)
SLACK ───────────┐ higher slack → reach cleaner hours
(deadline room) │ slack = 0 → savings = 0
▼
CI VARIANCE ─────► [ POTENTIAL SAVINGS ] ◄──── flat curve → savings = 0
(grid swing) │ ▲
│ │
CAPACITY M ───────┘ │ cap M limits how many jobs fit the green window
(per-hour cap) │ → some jobs pushed to dirtier hours (savings shrink)
│
LATENCY / FRESHNESS ───────┘ deferring delays the result (a real cost you pay)
┌───────────────── ACCOUNTING HONESTY ─────────────────┐
│ AVERAGE CI (what we report) vs MARGINAL CI (truth) │
│ REBOUND: cheap clean power may INDUCE more load │
│ TEMPORAL (move in time) vs SPATIAL (move in space) │
└──────────────────────────────────────────────────────┘
3. How it works (each tradeoff, one at a time)
3.1 Savings ⟷ SLACK
Slack = deadline − release − duration. It is the number of extra hours the job could shift. More slack means more candidate windows, so a higher chance the cleanest hour is reachable.
| Slack | Feasible windows | What you can hit |
|---|---|---|
| 0 | exactly 1 (must run now) | nothing — 0% savings |
| small | a few | maybe a slightly cleaner hour |
| large | many | the global daily minimum-CI window |
Rule: savings are monotonic non-decreasing in slack — more slack never hurts, and usually helps until you can already reach the single cleanest window (after which extra slack adds nothing).
3.2 Savings ⟷ CI VARIANCE
If the grid runs on one fuel all day, CI(t) is flat and every window is equally dirty — scheduling saves nothing. Savings need a swing: ISO-NE goes ~59 → ~350 (≈6×); CAISO swings hard on the solar "duck curve". Rule of thumb: savings ≈ (how far below the average the reachable minimum is), scaled by slack. No variance, no lever.
3.3 CAPACITY contention (per-hour cap M)
A shared power cap forces Σ_{jobs in hour h} P_j ≤ M. Jobs now compete for the greenest hours:
No cap: all jobs → the single cleanest window (each independently optimal)
Cap M: cleanest window fills up → later/tighter jobs pushed to dirtier hours
We schedule tightest-slack first (ascending-slack greedy): the job with the least room gets first pick of clean hours; roomier jobs absorb the displacement. The tighter M is, the more jobs spill into dirtier windows, and the lower the fleet savings.
3.4 LATENCY / freshness cost
Deferring is not free — the job's result arrives later. A nightly ML batch shifted from 8pm to 3am is fine; a dashboard refresh delayed 6 hours is stale and useless. Every deferral trades grams of CO₂ saved against hours of freshness lost. Latency-critical and interactive loads have ~0 slack by definition, so they are simply out of scope.
3.5 AVERAGE vs MARGINAL accounting
CI(t) as we compute it is an average intensity — the mean gCO₂/kWh across all generation that hour. But when you add or move a job, you don't change the average generator — you change the marginal one (the plant that ramps to meet the extra demand), which on many grids is gas. So:
| Basis | What it answers | Typical use |
|---|---|---|
| Average CI | "how dirty was the grid overall this hour?" | reporting, our backtest headline |
| Marginal CI | "what did my decision actually cause?" | attribution, Electricity Maps / WattTime |
Your average-basis saving is a fair, transparent number — but disclose that a marginal analysis may show a different figure. Interviewers love candidates who volunteer this.
3.6 The REBOUND effect
If clean power is cheap and plentiful, people use more of it (induced demand). A carbon-aware system that makes off-peak compute "free-feeling" may quietly grow total load, eating into the emissions it saved. Net impact ≠ per-job impact. Always separate "grams saved per job" from "grams saved in aggregate."
3.7 TEMPORAL vs SPATIAL shifting
Two independent axes:
TEMPORAL: move the job in TIME → run the batch at 3am instead of 8pm (this module)
SPATIAL: move the job in SPACE → run the batch in a region whose grid is
cleaner right now (follow-the-renewables)
Big cloud providers do both. Spatial shifting adds data-locality, egress, and latency costs (you must move the data or accept remote reads), and is bounded by where your data legally/practically lives. Temporal is simpler and needs no data movement — start there.
4. The math (plain notation + worked example)
4.1 Savings as a function of slack
Let Wmin(release, deadline, D) be the minimum-cost feasible window and Wfifo the FIFO (earliest) window:
cost(s) = Σ_{h=0}^{D-1} P·CI(s+h)
Savings%(slack) = ( cost(release) − min_{s∈[release, release+slack]} cost(s) )
─────────────────────────────────────────────────────────── × 100
cost(release)
As slack → 0 the min is taken over the single point s = release, so Savings% → 0. As slack grows, the min can only fall (or stay), so Savings% is non-decreasing in slack and saturates once the global-min window is reachable.
4.2 Capacity shrinks the reachable minimum
Under a cap M, the min is taken only over windows that still have room:
Savings%(M) uses min over { s : hour-capacity(s..s+D-1) ≥ P } (a SUBSET of windows)
Smaller M → fewer feasible clean windows → higher achievable min-cost → less savings
So Savings%(M) is non-decreasing in M: loosening the cap never hurts fleet savings.
4.3 Worked example — slack sweep on the ISO-NE curve
Same EV as the scheduling article: P = 7 kW, D = 3 h, release = 0, on
CI = [350,330,300,250,200,150,100,80,60,59,62,90,150]. Vary the deadline (hence slack) and recompute:
| deadline | slack | last start | min-cost window | greedy cost | FIFO cost | Savings% |
|---|---|---|---|---|---|---|
| 3 | 0 | 0 | s=0 (350,330,300) | 6,860 | 6,860 | 0.0% |
| 5 | 2 | 2 | s=2 (300,250,200) | 5,250 | 6,860 | 23.5% |
| 7 | 4 | 4 | s=4 (200,150,100) | 3,150 | 6,860 | 54.1% |
| 9 | 6 | 6 | s=6 (100,80,60) | 1,680 | 6,860 | 75.5% |
| 11 | 8 | 8 | s=8 (60,59,62) | 1,267 | 6,860 | 81.5% |
| 13 | 10 | 10 | s=8 (60,59,62) | 1,267 | 6,860 | 81.5% |
Read it top to bottom: slack 0 → 0% savings. Each extra hour of slack unlocks a cleaner window until slack 8 reaches the global-min window (2–5am); after that, more slack adds nothing (81.5% both at slack 8 and 10). That plateau is §4.1's saturation in action.
5. Real code (runnable Python)
A sensitivity function that sweeps savings vs slack and vs capacity M — the exact tool you'd use to decide whether carbon-aware scheduling is worth it for a given workload.
# ---------------------------------------------------------------------------
# sensitivity.py — savings as a function of SLACK and of CAPACITY M
# Reuses the same cost model as the carbon-aware scheduler. Runs as-is.
# ---------------------------------------------------------------------------
# Realistic ISO-NE overnight curve (index 0 = 6pm ... 12 = 6am), gCO2/kWh.
CI = [350, 330, 300, 250, 200, 150, 100, 80, 60, 59, 62, 90, 150]
def window_cost(ci, P, D, s):
"""cost(s) = sum_{h=0..D-1} P * CI(s+h) -> gCO2."""
return sum(P * ci[s + h] for h in range(D))
def savings_vs_slack(ci, P, D, release=0):
"""Return [(slack, savings%)] as the deadline (hence slack) grows."""
fifo = window_cost(ci, P, D, release) # earliest feasible start
rows = []
for deadline in range(release + D, len(ci) + 1):
slack = deadline - release - D
best = min(window_cost(ci, P, D, s)
for s in range(release, deadline - D + 1))
rows.append((slack, round((fifo - best) / fifo * 100, 1)))
return rows
def savings_vs_capacity(ci, jobs, caps):
"""Fleet savings% for each per-hour cap M in `caps`.
jobs: list of (P, D, release, deadline). Tightest-slack-first greedy.
"""
def fifo_total():
return sum(window_cost(ci, P, D, rel) for (P, D, rel, _dl) in jobs)
def greedy_total(M):
remaining = [M] * len(ci)
total = 0.0
order = sorted(jobs, key=lambda j: j[3] - j[2] - j[1]) # ascending slack
for (P, D, rel, dl) in order:
feasible = [s for s in range(rel, dl - D + 1)
if all(remaining[s + h] >= P for h in range(D))]
if not feasible:
raise RuntimeError("no feasible window under cap M=%s" % M)
s = min(feasible, key=lambda s: window_cost(ci, P, D, s))
for h in range(D):
remaining[s + h] -= P
total += window_cost(ci, P, D, s)
return total
base = fifo_total()
return [(M, round((base - greedy_total(M)) / base * 100, 1)) for M in caps]
if __name__ == "__main__":
print("SAVINGS vs SLACK (single EV, P=7, D=3):")
for slack, pct in savings_vs_slack(CI, P=7, D=3):
bar = "#" * int(pct // 3)
print(f" slack={slack:>2}h {pct:>5.1f}% {bar}")
print("\nSAVINGS vs CAPACITY M (3 EVs due by 7am):")
fleet = [(7, 3, 0, 13), (7, 3, 0, 13), (7, 2, 0, 13)] # P,D,release,deadline
for M, pct in savings_vs_capacity(CI, fleet, caps=[7, 14, 15, 21, 999]):
print(f" M={M:>4} kW -> {pct:>5.1f}% fleet savings")
# Expected (abridged):
# slack= 0h 0.0%
# slack= 2h 23.5% #######
# slack= 4h 54.1% ##################
# slack= 8h 81.5% ###########################
# slack=10h 81.5% ###########################
# M= 7 kW -> ~71.6% (one charger at a time: heavy contention)
# M= 14 kW -> ~79.5% (two at a time: EV-C pushed off the greenest hour)
# M= 999 kW -> ~81.8% (no cap: everyone gets a clean window)
The two sweeps are the whole message in code: savings climb with slack then plateau, and savings climb as the capacity cap loosens.
6. Real-world example (concrete, with numbers)
Should we make our nightly ML training carbon-aware? A team runs a P = 40 kW GPU cluster job, D = 4 h, released at 8pm, needed by 8am (slack = 8 h). On the ISO-NE overnight curve the analysis says:
- Slack check: 8 h of slack easily reaches the 2–5am clean window → ~80% per-job savings possible. Green light.
- Capacity check: the cluster's feeder caps concurrent jobs. If five teams all defer into 2–5am and the cap only fits three, two spill to midnight–2am (
CI~100 vs ~60) — fleet savings drop from ~80% to the mid-70s. Stagger deadlines so not everyone targets the same hour. - Latency check: results by 8am is the only requirement, so freshness cost ≈ 0. No conflict.
- Accounting check: report average-basis ~80% saving, and add a line: "on a marginal basis (gas on the margin at 2am), avoided emissions may be lower; see WattTime." Honest and defensible.
Counter-example — don't bother. A real-time fraud-scoring service (slack = 0, latency-critical) and a coal-baseload grid (CI nearly flat) each yield ~0% savings. The sensitivity function returns near-zero and tells you to spend your effort elsewhere.
The discipline of proving the savings before committing is a backtest; the discipline of sweeping slack/M and reporting honest limits is sensitivity analysis — see Backtesting, Baselines & Sensitivity Analysis.
7. Interview questions companies actually ask
Q [easy] "Why isn't carbon-aware scheduling a free 80% saving on everything?"
A Savings are the product of SLACK and CI VARIANCE, minus CAPACITY contention and LATENCY
cost. No slack or a flat grid gives ~0%. It's a set of coupled tradeoffs, not one dial.
Q [easy] "What single factor most limits your savings?"
A Slack. Savings are non-decreasing in slack and hit 0 when slack=0 — the job must run now,
so there's no cleaner window to move into, regardless of how variable the grid is.
Q [medium] "How does a per-hour capacity cap change the outcome?"
A It forces sum(P_j) <= M each hour, so jobs contend for the greenest window and some get
pushed to dirtier hours. Savings are non-decreasing in M; schedule tightest-slack first so
the least-flexible jobs get first pick. (Google/Microsoft datacenters hit exactly this.)
Q [medium] "Average vs marginal emissions — why does the distinction matter?"
A Average CI is the mean over all generation; marginal is the plant your decision actually
moves (often gas). Your average-basis saving can look different on a marginal basis. Report
average transparently, disclose the marginal caveat, cite Electricity Maps / WattTime.
Q [medium] "What is the rebound effect here?"
A Making clean off-peak compute cheap can INDUCE more total load, so aggregate emissions fall
less than the per-job number implies. Separate 'grams saved per job' from 'grams saved in
total' — net impact can undercut the headline.
Q [hard] "Temporal vs spatial shifting — when would you pick spatial?"
A Temporal moves the job in time (no data movement, simplest). Spatial moves it to a cleaner
region right now, but adds data-locality, egress, and latency costs and is bounded by where
your data can live. Pick spatial when a remote grid is far cleaner AND the data is movable.
Q [hard] "A stakeholder wants carbon-aware scheduling on a latency-critical service. Response?"
A It won't help: latency-critical = ~0 slack by definition, so ~0% savings, and deferring
breaks the SLA. Point them at deferrable loads (batch/EV/thermal) instead, and quantify with
a slack sweep so the 0% is evidence, not opinion.
Q [hard] "How do you decide, quantitatively, whether it's worth it for a given workload?"
A Run a sensitivity analysis on historical data: sweep savings vs slack and vs capacity M on
a backtest against FIFO. If savings at the workload's real slack/M are material (say >10-15%)
it's worth it; if the curve is flat or near-zero, it isn't. Let the numbers decide.
Q [hard] "Your backtest shows 80% but production shows less. Why?"
A Backtests use perfect historical CI (no forecast error) and often assume no capacity
contention. Production adds forecast error (future CI is uncertain), capacity caps pushing
jobs off clean hours, rebound, and average-vs-marginal gaps. The 80% is an upper bound.
8. When to use / tradeoffs (the honest cheat sheet)
WORTH IT NOT WORTH IT
-------- ------------
+ deferrable load with real slack - latency-critical / interactive (slack ~ 0)
+ high CI variance (wind/solar grids) - flat CI curve (single-fuel baseload)
+ freshness cost of delay is low - tight SLA where deferral breaks the contract
+ fleet-level capacity has headroom - a hard capacity cap that blocks clean windows
+ you can report honest average+marginal - stakeholders who want one guaranteed % on all loads
| Lever | Push it up and you get | The cost |
|---|---|---|
| Slack | more clean windows reachable → higher savings | result arrives later (latency) |
| CI variance | bigger swing to exploit | you don't control the grid |
Capacity M | more jobs fit the greenest hour | more infrastructure / power headroom |
| Spatial shift | reach a cleaner grid | data egress, locality, latency |
Core tension: every gram saved by deferring buys you later results, competes for shared capacity, and is measured on an average basis that a marginal analysis may revise. State all of it — that honesty is the senior signal.
9. Summary + related articles
- Carbon-aware scheduling is coupled tradeoffs, not one number: slack, CI variance, capacity, latency, and accounting honesty.
- Savings ⟷ slack: non-decreasing in slack, 0% at slack 0, and it plateaus once the global-min clean window is reachable.
- A capacity cap
Mmakes jobs contend → some pushed to dirtier hours; savings are non-decreasing inM; schedule tightest-slack first. - Latency/freshness is the price of deferring; average vs marginal and the rebound effect can revise the headline downward.
- Temporal (move in time) vs spatial (move to a cleaner region) shifting — temporal is simpler; spatial adds data-movement cost.
- Decide with a sensitivity sweep on a backtest; if the curve is flat, don't do it.
Related: Carbon-Aware Scheduling of Flexible Loads · Emission Factors & Carbon Accounting · Backtesting, Baselines & Sensitivity Analysis · Green / Carbon-Aware Systems — Interview Questions
Resources
- Electricity Maps — average & marginal carbon intensity — https://www.electricitymaps.com/
- WattTime — marginal emissions & AER methodology — https://www.watttime.org/
- Google — Carbon-intelligent computing platform — https://blog.google/inside-google/infrastructure/data-centers-work-harder-sun-shines-wind-blows/
- Microsoft — carbon-aware computing & the Carbon Aware SDK — https://devblogs.microsoft.com/sustainable-software/
- Rebound effect (energy efficiency) — overview — https://en.wikipedia.org/wiki/Rebound_effect_(conservation)
- The Green Software Foundation — carbon-aware patterns — https://learn.greensoftware.foundation/