GreenOps

GreenOps is the practice of measuring and reducing the greenhouse-gas emissions caused by running software and IT infrastructure. For every workload it asks how much energy it uses, how carbon-intensive that energy is and how much manufactured hardware it ties up, and sets the answers beside cost, latency and reliability.

Forrester analysts define it as “the practice of minimizing a cloud environment’s carbon footprint through the efficient use of cloud resources” and note that “GreenOps looks a lot like FinOps”.^[1] The FinOps Foundation does not use the word; it describes a Sustainability capability that incorporates “sustainability criteria and metrics into FinOps activities”.^[2] The main software-level measurement specification is Software Carbon Intensity (SCI) from the Green Software Foundation (GSF), adopted as ISO/IEC 21031:2024.^[3][4]

This page’s emphasis is carbon-accounting literacy for engineers: what the numbers mean, how uncertain they are, and where carbon and cost optimisation part company; generic cost optimisation lives in FinOps.

For engineers asked for “the carbon number”, FinOps and sustainability practitioners joining carbon to cost, and leaders deciding how much effort carbon deserves (learning path).

The International Energy Agency’s April 2026 update projects data-centre electricity use “roughly doubling from 485 TWh in 2025 to 950 TWh in 2030”, with AI-focused data centres growing fastest, and stresses “uncertain trends”.^[8] Carbon figures arrive from providers, sustainability teams and regulators, and rarely agree. Without a shared method, one region is “low carbon” by one metric and among the dirtiest by another (what the numbers mean); teams shift batch jobs by the hour while idle servers run all month; a method switch or certificate purchase is shown as an engineering saving; and a three-year reservation locks in capacity nobody will later rightsize.^[2]

• Not FinOps with a green logo. Most usage optimisation lowers both cost and carbon,^[2] but the two diverge often enough to need their own analysis (where they diverge).
• Not offsetting. Under SCI, “Neutralization or avoidance offsets do not reduce an SCI score”.^[7]
• Not corporate environmental, social and governance (ESG) reporting. GreenOps supplies IT data to it; the disclosure itself belongs to the sustainability function and ComplianceOps.
• Not a product, although Forrester’s tool list includes one called GreenOps.^[1]
• Not only the cloud. Capgemini uses GreenOps for sustainable practice across an organisation’s operations;^[5] this page covers cloud, data centres and end-user devices, and leaves supply chains to SupplyChainOps.

Mental model: one equation, three levers, one unit. Emissions = energy × intensity + embodied share, per unit of useful work; SCI groups every reduction into energy efficiency, hardware efficiency and carbon awareness.^[7] Contracts change only the market-based figure; offsets are reported separately from the scopes and change neither figure.^[6]

%%{init: {"flowchart": {"wrappingWidth": 110, "nodeSpacing": 16, "rankSpacing": 36}}}%%
flowchart TB
  L1["Energy efficiency: rightsizing, less work"] --> E["Energy E in kWh, including PUE"]
  L2["Carbon awareness: shift time or place"] --> I["Grid intensity I in gCO2e per kWh"]
  L3["Hardware efficiency: utilisation, longer life"] --> M["Embodied share M = TE x TS x RS"]
  E --> O["Operational O = E x I"]
  I --> O
  R["Functional unit R: requests, jobs, users"]
  O --> S["SCI = (O + M) per R"]
  M --> S
  R --> S
  S -.-|"excludes"| OUT
  subgraph OUT["Outside SCI"]
    X["Certificates, PPAs, supplier rates"] -.-> MB["Market-based Scope 2: energy x contract factors, inventory only"]
    Y["Offsets"] -.-> Z["Reported apart from the scopes; reduce neither Scope 2 nor SCI"]
  end
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class L1,L2,L3 core
  class E,I,M,O,S,R neutral
  class X,MB,Y,Z risk
  style OUT stroke:#b4332b,stroke-dasharray:6 4

The boundaries below are editorial distinctions of this Atlas, not industry standards.

In the cloud you inherit the provider’s boundary: AWS, for example, excludes Outposts and other sites in customer facilities.^[18]

The GHG Protocol defines two Scope 2 methods. A location-based method “reflects the average emissions intensity of grids on which energy consumption occurs”; a market-based method “reflects emissions from electricity that companies have purposefully chosen (or their lack of choice)”, using contracts such as certificates, PPAs and supplier rates.^[6] Where such contracts exist, companies report both (“dual reporting”).^[6]

Market-based figures have a legitimate job. Where contracts “convey legally enforceable claims”, companies setting goals “should use the market-based method total for goals”; the Guidance adds that one target per method can help prioritise new low-carbon projects, and asks companies to explain, where relevant, how their instruments reflect “a substantive contribution” to such projects.^[6] A PPA that funds new clean capacity is a real lever for a corporate target. This page’s narrower editorial rule: engineering claims (SCI, design reviews) use location-based or SCI figures, because a contract changes no workload’s kilowatt-hours.

The gap is large. Across Google’s data centres the 2024 average factor was 345 gCO2e/kWh location-based and 94 market-based after its clean-energy purchases.^[24] Google’s region table shows how this flips rankings (2025 data):^[21]

By the location-based grid Frankfurt is about 45% cleaner than Warsaw; by Google’s CFE%, which counts Google’s own contracts hour by hour, Warsaw is the “low carbon” choice. Both are right, about different questions. CFE% is not a GHG Protocol method: Google’s market-based customer figures scale location-based ones down by the previous year’s renewable share.^[22] SCI uses grid intensity “which excludes any market-based measures”;^[7] AWS advises: “Choose region based on method you use to track carbon emissions.”^[25]

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 18, "rankSpacing": 36}}}%%
flowchart TB
  K["Electricity used by the workload, kWh"] --> LB["Location-based: grid-average intensity where it runs"]
  K --> MG["Marginal: generator that answers extra load"]
  K --> MB["Market-based: contracts, certificates, PPAs, residual mix"]
  LB --> U1["Engineering trade-offs, location-based Scope 2"]
  LB --> SC["SCI: average or marginal, never market-based"]
  MG --> SC
  MG --> U3["Short-term scheduling, contested between data vendors"]
  MB --> U2["Corporate inventory, market-based Scope 2, supplier claims"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class K neutral
  class LB,MB,MG decision
  class U1,U2,U3,SC core

The rules are moving. In October 2025 the GHG Protocol consulted on “a new hourly matching and deliverability requirement for market-based reporting”, keeping dual reporting.^[16] In July 2026 it said it would explore whether to offer “multiple reporting approaches” and set a new timeline: a joint consultation with ISO in Q2 2027 and one GHG Protocol–ISO 14064-1 corporate standard in Q4 2028.^[26] Expect market-based figures to change more than location-based ones (as of October 2026).

For deciding when to run, two data vendors disagree. WattTime’s marginal operating emissions rate “represents the emissions rate of the electricity generator(s) that are responding to changes in load on the local grid at a certain time”, and it explains why a hydro-rich region can show a high marginal rate: its exports fall and fossil plants next door ramp up.^[19] Electricity Maps argues the marginal signal “misses the long-term benefits” of using clean hours, while the average signal “incentivizes using electricity during times when the grid is clean”.^[27] SCI accepts short-run marginal, long-run marginal or average intensity,^[7] so the choice is a policy decision: write it down, apply it consistently, and expect the two signals to pick different hours (Lab 2).

SCI allocates embodied carbon by time share and resource share: M = TE × (time reserved ÷ expected lifespan) × (resources reserved ÷ total resources); its example of a 1,000 kg device over four years gives about 28 g per reserved hour.^[7] Two consequences:

• Lifetime is a lever. GSF’s example: extending a 4,000 kg server from four to five years cuts the amortised figure from 1,000 to 800 kg a year.^[20]
• Idle hardware still emits. “It’s better to use one server at 100% utilization than 5 servers at 20% utilization.”^[20]

Dell’s life-cycle assessment (LCA) of a two-socket PowerEdge R760 (two 12-core CPUs, two SSDs, four-year life) gives 4,177 kg CO2e in a US scenario and 2,896 kg in an EU one, with the use phase at about 87–91% and manufacturing at about 10–15%^[28] (roughly 420–435 kg by this page’s arithmetic). On a clean grid embodied carbon dominates (Lab 1).

PUE multiplies IT energy: 10 kWh at a PUE of 1.5 draws 15 kWh.^[9] Google reports a 2025 fleet PUE of 1.09 and cites the Uptime Institute’s 2025 survey average of 1.54;^[29] Uptime notes “little change for the sixth consecutive year”.^[30] EU data centres with at least 500 kW of IT power report PUE, WUE, energy reuse (ERF) and renewable energy (REF) factors every year (by 15 May since 2025).^[12]

The practical rule: report a range, name the boundary and method, and decide only when the options differ by more than the uncertainty. The FinOps Foundation agrees: use available data “even when it is incomplete” and document its limitations.^[2]

No official GreenOps manifesto exists; this charter is this Atlas’s proposal, built on SCI and the FinOps Sustainability capability.^[7][2] Mission: cut the emissions of each unit of digital work, measured on physical energy and hardware, without hiding regressions in cost, latency or resilience.

1. Per unit of work: review “the resources and emissions required per unit of work”^[33] (AWS); totals rise with growth.
2. Reduce before you buy: certificates and offsets never reduce SCI.^[7]
3. Name the method: every figure carries method, boundary, scopes, source and model version.
4. Ranges, not points: decide only beyond the uncertainty.
5. One review: carbon sits with cost, latency and reliability; trade-offs are recorded.^[2]
6. Hardware is carbon: utilisation and lifetime count as much as electricity.^[20]

Non-goals: a perfect inventory before acting; moving regulated data for a small carbon gain; carbon targets that erode service level objectives (SLOs).

The FinOps Foundation spreads sustainability work across its personas, including allied sustainability personas.^[2] This Atlas proposes a part-time GreenOps lead in the FinOps or platform team, and this RACI:

• Cadence. Monthly ledger refresh after providers publish (Google on the 15th, Azure by the 19th, AWS by the 21st);^[34][35][32] quarterly target review; annual method review aligned with the corporate inventory.
• Gates. Region choices, new large workloads and hardware purchases carry a carbon line with a range (templates).
• Escalation. The owner records any carbon–cost or carbon–latency trade-off; leadership settles those above a set threshold.^[2]

The core artefact is a carbon ledger in which every figure records what it measures and how.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 18, "rankSpacing": 34}}}%%
flowchart TB
  P["Provider exports: monthly, provider boundary, Scopes 1-3"]
  U["Usage and telemetry"] --> EST["Estimator: SCI low, central, high"]
  F["Grid intensity, PUE, hardware LCAs"] --> EST
  P --> N["Normalise: tag method, scope, boundary, model version"]
  EST --> N
  N --> L["Carbon ledger"]
  L -- "provider rows" --> REP["Reporting: disclosure inputs, trends"]
  L -- "estimate rows" --> DEC["Decisions: ADRs, refresh, schedules, guardrails"]
  L --> RC{{"Estimate and export reconcile?"}}
  RC -- "Yes" --> OK["Note in the monthly review"]
  RC -- "No" --> X["Explain: boundary, scopes, PUE, method, version"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class P,REP,N,L,OK neutral
  class U,F,EST,DEC core
  class RC decision
  class X risk

Why two pipelines: provider exports hold facility and Scope 1–3 data you cannot see but arrive monthly;^[32] estimates can price a design before it exists.

%%{init: {"flowchart": {"wrappingWidth": 170, "nodeSpacing": 24, "rankSpacing": 30}}}%%
flowchart TB
  T["Trigger: new workload, region move, refresh or schedule change"] --> B["Baseline and proposal SCI: same method, with ranges"]
  B --> D{{"Difference beyond the uncertainty?"}}
  D -- "No" --> K["Decide on cost, latency and reliability"]
  D -- "Yes" --> C{{"Conflict with cost, latency, residency or SLO?"}}
  C -- "No" --> A["Adopt and record in the ADR"]
  C -- "Yes" --> E["Record the trade-off; escalate above threshold"]
  E --> A
  A --> V{{"Reduction visible in the ledger one to two months later?"}}
  V -- "Yes" --> R["Update baseline and pattern library"]
  V -- "No" --> X["Investigate: method change, usage growth, boundary"]
  X --> B
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class T,B,K,A,R core
  class D,C,V decision
  class E,X risk

SCI requires that the baseline use “an identical methodology” except for the action being assessed.^[7] Many false “savings” compare a new estimate with an old figure from another method.

1. Qualify: the job can wait hours (temporal) or run elsewhere (spatial) within residency rules.^[36]
2. Choose and record the signal (average or marginal) and its data source.
3. Estimate run-now and best-window options; ignore gains smaller than the forecast error.
4. Implement with a deadline guard: the job always starts by its latest start time, whatever the forecast says.
5. Verify monthly with the same signal. Simple policies capture most of the benefit, which shrinks as grids get cleaner.^[37]
6. Roll back if the rule delays downstream consumers or breaches the job’s SLO.

Only the regulation is mandatory, and only within its scope; this table is not legal advice (ComplianceOps).

Selection criteria: scopes and methods covered, granularity, data lag and retention, exported methodology versions, and reconcilability with provider figures.

As of October 2026; check release notes before relying on a row.

Automation earns its place in three spots: the monthly export and ledger load (unexported data is lost when retention or methodology changes), schedulers with deadline guards, and guardrails as code. Treat Azure’s “AI-driven” recommendations, such as switching SKUs and shutting down idle resources,^[35] like rightsizing advice verified against SLOs. AI is also a subject: the FinOps capability calls AI workloads “materially more energy-intensive than general-purpose compute”,^[2] and their numbers depend on the boundary (Case 3). AI unit economics belong to FinOps for AI; model-serving efficiency to LLMOps.

Assumptions (illustrative): checkout-api reserves 24 vCPUs on shared cloud hosts in a region whose grid averaged 276 gCO2e/kWh in 2025 (Google’s europe-west3 value^[21]) and serves 78 million requests a month.

1. Service card. Each uncertain input is [low, central, high]. Central coefficients are Cloud Carbon Footprint’s AWS values (0.74 and 3.5 W per vCPU, 1.2 Wh per SSD TB-hour, 0.001 kWh/GB, PUE 1.135);^[31] the low PUE is Google’s 2025 fleet value.^[29] Embodied carbon runs from Dell’s R760 manufacturing share scaled from its 48 threads to this host’s 96 vCPUs (about 840 kg, a linear assumption) to twice SCI’s 1,000 kg example, and lifespans from four years (Dell, SCI) to six (AWS).^[7][28][13] Other ranges are this page’s assumptions.

Example status: verified by execution (Python 3.8.10, 2026-10-17) together with the script below.

{
  "service": "checkout-api",
  "period_hours": 720,
  "functional_unit": {"name": "1,000 requests", "size": 1000,
                      "count_in_period": 78000000},
  "compute": {
    "vcpus_reserved": 24,
    "cpu_utilisation": [0.15, 0.20, 0.25],
    "watts_per_vcpu_idle": [0.52, 0.74, 0.96],
    "watts_per_vcpu_max": [2.45, 3.50, 4.55]
  },
  "storage_tb_ssd": 2.0,
  "storage_wh_per_tb_hour": [0.6, 1.2, 1.8],
  "network_gb_between_regions": 100,
  "network_kwh_per_gb": [0.001, 0.001, 0.01],
  "pue": [1.09, 1.135, 1.20],
  "grid_gco2e_per_kwh": [207, 276, 345],
  "embodied": {
    "host_kgco2e": [840, 1000, 2000],
    "host_lifespan_years": [6, 5, 4],
    "host_vcpus": 96
  }
}

2. Estimator. It applies SCI’s formulas, evaluates every low/high corner and ranks which input moves the result most.

Example status: verified by execution (Python 3.8.10, 2026-10-17); the output below is the actual output.

"""Estimate a Software Carbon Intensity (SCI) score with low / central / high bounds.

SCI = (E * I + M) per R, following the Green Software Foundation SCI specification
(ISO/IEC 21031:2024). Every uncertain input is a [low, central, high] triple; the script
evaluates every low/high corner, so the bounds are worst and best cases, not a confidence
interval. Standard library only.  Usage: python3 sci_estimate.py service-card.json
"""
import itertools
import json
import sys

UNCERTAIN = [
    ("cpu_utilisation", ("compute", "cpu_utilisation")),
    ("watts_per_vcpu_idle", ("compute", "watts_per_vcpu_idle")),
    ("watts_per_vcpu_max", ("compute", "watts_per_vcpu_max")),
    ("storage_wh_per_tb_hour", ("storage_wh_per_tb_hour",)),
    ("network_kwh_per_gb", ("network_kwh_per_gb",)),
    ("pue", ("pue",)),
    ("grid_gco2e_per_kwh", ("grid_gco2e_per_kwh",)),
    ("host_kgco2e", ("embodied", "host_kgco2e")),
    ("host_lifespan_years", ("embodied", "host_lifespan_years")),
]


def lookup(card, path):
    node = card
    for key in path:
        node = node[key]
    return node


def score(card, v):
    """Return (operational_g, embodied_g, energy_kwh) for one set of input values."""
    hours = card["period_hours"]
    c = card["compute"]
    watts = c["vcpus_reserved"] * (v["watts_per_vcpu_idle"] + v["cpu_utilisation"]
                                   * (v["watts_per_vcpu_max"] - v["watts_per_vcpu_idle"]))
    it_kwh = (watts * hours
              + card["storage_tb_ssd"] * v["storage_wh_per_tb_hour"] * hours) / 1000
    it_kwh += card["network_gb_between_regions"] * v["network_kwh_per_gb"]
    energy_kwh = it_kwh * v["pue"]                      # E: includes facility overhead
    operational_g = energy_kwh * v["grid_gco2e_per_kwh"]  # O = E * I
    e = card["embodied"]
    time_share = hours / (v["host_lifespan_years"] * 8760)
    resource_share = c["vcpus_reserved"] / e["host_vcpus"]
    embodied_g = v["host_kgco2e"] * 1000 * time_share * resource_share  # M = TE * TS * RS
    return operational_g, embodied_g, energy_kwh


def per_unit(card, grams):
    fu = card["functional_unit"]
    return grams / (fu["count_in_period"] / fu["size"])


def main(path):
    with open(path, encoding="utf-8") as fh:
        card = json.load(fh)
    central = {name: lookup(card, p)[1] for name, p in UNCERTAIN}
    o, m, e = score(card, central)
    totals = []
    for corner in itertools.product((0, 2), repeat=len(UNCERTAIN)):
        vals = {name: lookup(card, p)[i] for (name, p), i in zip(UNCERTAIN, corner)}
        totals.append(sum(score(card, vals)[:2]))
    unit = card["functional_unit"]["name"]
    print(f"SCI estimate for {card['service']} ({card['period_hours']} h)")
    print(f"  energy E (incl. PUE)      {e:8.1f} kWh")
    share_o, share_m = 100 * o / (o + m), 100 * m / (o + m)
    print(f"  operational O = E x I     {o / 1000:8.2f} kgCO2e ({share_o:.0f}%)")
    print(f"  embodied M = TE x TS x RS {m / 1000:8.2f} kgCO2e ({share_m:.0f}%)")
    print(f"  SCI central  {per_unit(card, o + m):.3f} gCO2e per {unit}")
    low, high = per_unit(card, min(totals)), per_unit(card, max(totals))
    print(f"  SCI range    {low:.3f} to {high:.3f} gCO2e per {unit}"
          " (best and worst corners)")
    print("SENSITIVITY (swing of the SCI when one input moves from low to high)")
    swings = []
    for name, p in UNCERTAIN:
        lo, hi = dict(central), dict(central)
        lo[name], hi[name] = lookup(card, p)[0], lookup(card, p)[2]
        swings.append((abs(sum(score(card, hi)[:2]) - sum(score(card, lo)[:2])), name))
    for swing, name in sorted(swings, reverse=True):
        print(f"  {name:<24} {per_unit(card, swing):.3f} gCO2e per {unit}")
    return 0


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("usage: python3 sci_estimate.py <service-card.json>")
    sys.exit(main(sys.argv[1]))

$ python3 sci_estimate.py service-card.json
SCI estimate for checkout-api (720 h)
  energy E (incl. PUE)          27.4 kWh
  operational O = E x I         7.57 kgCO2e (65%)
  embodied M = TE x TS x RS     4.11 kgCO2e (35%)
  SCI central  0.150 gCO2e per 1,000 requests
  SCI range    0.080 to 0.321 gCO2e per 1,000 requests (best and worst corners)
SENSITIVITY (swing of the SCI when one input moves from low to high)
  host_kgco2e              0.061 gCO2e per 1,000 requests
  grid_gco2e_per_kwh       0.049 gCO2e per 1,000 requests
  watts_per_vcpu_max       0.029 gCO2e per 1,000 requests
  watts_per_vcpu_idle      0.024 gCO2e per 1,000 requests
  host_lifespan_years      0.022 gCO2e per 1,000 requests
  cpu_utilisation          0.019 gCO2e per 1,000 requests
  pue                      0.009 gCO2e per 1,000 requests
  storage_wh_per_tb_hour   0.007 gCO2e per 1,000 requests
  network_kwh_per_gb       0.004 gCO2e per 1,000 requests

How to read it. The honest answer is “0.08 to 0.32 g per 1,000 requests”, a factor of four around 0.150. The input that moves it most is the one nobody measured, the host’s embodied carbon, so the first action is a question to the supplier, not an optimisation.

3. Ledger record, stored for every figure, estimated or exported. SCI requires every component that significantly contributes,^[7] so each exclusion carries its reason.

Example status: JSON syntax-checked; values from the estimator above.

{
  "service": "checkout-api",
  "month": "2026-09",
  "source": "estimate: sci_estimate.py, service-card 2026-09",
  "method": "location-based",
  "signal": "annual average, 2025 grid factor",
  "boundary": ["compute", "ssd-storage", "inter-region-network", "pue", "embodied-share"],
  "excluded": {
    "memory": "inside the per-vCPU watts, derived from whole-server measurements",
    "end-user devices": "customers' browsers; excluded by ADR-041 until estimated",
    "build pipelines": "assumed under 1% of vCPU-hours; re-check quarterly"
  },
  "functional_unit": "1,000 requests",
  "kgco2e": {"low": 6.25, "central": 11.68, "high": 25.05},
  "sci_g_per_unit": {"low": 0.080, "central": 0.150, "high": 0.321},
  "owner": "checkout-team"
}

4. Provider data beside cost (Google Cloud). Carbon Footprint exports a monthly carbon_footprint table on the 15th of the following month, with both methods and a carbon_model_version.^[34][44] Joined by usage month, billing data may include late-reported usage and will not match the invoice exactly.^[46]

Example status: not executed and not parsed (no BigQuery dataset available); field names checked against Google’s schema pages on 2026-10-17.

-- Carbon (both methods) and net cost per project and usage month. BigQuery Standard SQL.
WITH carbon AS (
  SELECT usage_month,
         project.id AS project_id,
         SUM(carbon_footprint_total_kgCO2e.location_based) AS kg_location,
         SUM(carbon_footprint_total_kgCO2e.market_based) AS kg_market,
         MAX(carbon_model_version) AS model_version
  FROM `PROJECT.DATASET.carbon_footprint`
  GROUP BY usage_month, project_id
),
cost AS (
  SELECT DATE_TRUNC(DATE(usage_start_time), MONTH) AS usage_month,
         project.id AS project_id,
         SUM(cost + IFNULL((SELECT SUM(c.amount) FROM UNNEST(credits) AS c), 0))
           AS net_cost
  FROM `PROJECT.DATASET.gcp_billing_export_v1_BILLING_ACCOUNT_ID`
  GROUP BY usage_month, project_id
)
SELECT c.usage_month, c.project_id, c.kg_location, c.kg_market,
       SAFE_DIVIDE(c.kg_location, c.kg_market) AS method_gap_ratio,
       k.net_cost,
       1000 * SAFE_DIVIDE(c.kg_location, k.net_cost) AS kg_location_per_1000_cost,
       c.model_version
FROM carbon AS c
LEFT JOIN cost AS k USING (usage_month, project_id)
ORDER BY c.usage_month DESC, c.kg_location DESC;

Other clouds feed the same ledger columns. AWS Data Exports deliver a monthly CARBON_EMISSIONS table to Amazon S3, partitioned by model_version and usage_period, so restated versions sit beside old ones;^[47][32] Azure carbon optimization has a REST API and CSV export but keeps only 12 months, so export monthly.^[35]

Example status: not executed (no AWS account); column names checked against AWS’s column list on 2026-10-17;^[48] DATABASE.carbon_emissions_export stands for your Athena table over the export.

-- AWS Data Exports CARBON_EMISSIONS, queried with Amazon Athena. Values are in MTCO2e.
SELECT usage_period_start, usage_account_id, region_code, model_version,
       1000 * SUM(total_lbm_emissions_value) AS kg_location,
       1000 * SUM(total_mbm_emissions_value) AS kg_market
FROM DATABASE.carbon_emissions_export
GROUP BY usage_period_start, usage_account_id, region_code, model_version
ORDER BY usage_period_start DESC, kg_location DESC;

5. Guardrail (Google Cloud). The policy allows new resources in a folder only in Google’s in:eu-low-carbon-locations value group (europe-north1, europe-southwest1, europe-west1, europe-west9 as of October 2026).^[49] Preconditions:

• Scope: it “controls only where resources are created” and skips global resources.^[49]
• No dry run: this constraint cannot run in dry-run mode, so test it on a non-production folder.^[50]
• Meaning: a “low carbon” location must have CFE% ≥ 75% (or, without CFE% data, ≤ 200 gCO2e/kWh),^[21] and the groups list only some such regions (not Warsaw).^[49] The US group admits us-central1 at 432 gCO2e/kWh location-based, more than the excluded us-east4 (343).^[21]
• Residency first: a folder’s own policy by default “supersedes any policy set by its parent resources”, so this one replaces an organisation’s residency allow-list, and inheritFromParent: true would merge the two into a wider one.^[51] List only regions both allow; compare gcloud org-policies describe gcp.resourceLocations --folder=FOLDER_ID --effective before and after.

Example status: YAML syntax-checked; not applied (needs an organisation and roles/orgpolicy.policyAdmin).

# Folder-level allow list: new resources only in Google's EU "low carbon" locations.
# gcp.resourceLocations cannot be dry-run; apply to a test folder first.
# This REPLACES any inherited location policy for the folder. Under a residency policy,
# list only regions it also allows: in:de-locations (Germany) shares none with this group.
name: folders/FOLDER_ID/policies/gcp.resourceLocations
spec:
  rules:
    - values:
        allowedValues:
          - in:eu-low-carbon-locations

Apply with gcloud org-policies set-policy low-carbon-locations.yaml (enforcement can take up to 15 minutes);^[49] roll back by restoring the previous YAML. Other clouds’ equivalents belong to CloudOps.

Objective: an SCI range for one service, and the lever that moves it most. Prerequisites: Python 3.8 or later; no cloud account, cost or risk.

1. Save the service card as service-card.json and the estimator as sci_estimate.py; run python3 sci_estimate.py service-card.json.
2. Rightsize: set vcpus_reserved to 12 and cpu_utilisation to [0.30, 0.40, 0.50]; run again.
3. Move to a clean grid: restore the card, set grid_gco2e_per_kwh to [22, 30, 38] (europe-north1’s 2025 average was 30^[21]); run again.
4. Replace the inputs with your service’s vCPUs, utilisation percentiles, requests and region.

Expected output (checked by execution). Step 1: the reference output, exit 0. Step 2: central 0.098, range 0.049–0.211 (35% lower, at half the vCPU cost). Step 3: central 0.063, range 0.041–0.153, embodied now 83%: on a clean grid, hardware dominates. Validation: the central value lies inside the range. Troubleshooting: KeyError means a renamed field; a range that excludes the central value means a triple out of order (lifespan runs long to short). Teardown: delete the files.

Objective: compare options for a deferrable nightly job under two carbon signals and cost. Prerequisites: Python 3.8 or later; no cost or risk. The hourly series and prices are illustrative (a grid with midday solar and evening peakers); the other region’s 30 gCO2e/kWh is Google’s 2025 europe-north1 average.^[21]

Example status: verified by execution (Python 3.8.10, 2026-10-17); the output below is the actual output.

{
  "job": {"name": "nightly-etl", "facility_kwh": 40.0, "hours": 3,
          "earliest_start_hour": 18, "must_finish_within_hours": 24,
          "compute_cost": 60.0},
  "home": {
    "region": "home-region",
    "average_gco2e_per_kwh": [310, 300, 295, 290, 295, 310, 320, 300, 260, 210, 170, 140,
                              125, 120, 130, 160, 210, 280, 340, 360, 350, 335, 325, 315],
    "marginal_gco2e_per_kwh": [380, 380, 380, 380, 380, 380, 430, 430, 430, 430, 440, 440,
                               440, 440, 440, 440, 440, 520, 520, 520, 520, 520, 430, 430]
  },
  "alternative": {
    "region": "europe-north1", "annual_average_gco2e_per_kwh": 30,
    "residency_allowed": true, "compute_price_factor": 1.08,
    "data_moved_gb": 520, "egress_price_per_gb": 0.02,
    "network_kwh_per_gb": [0.001, 0.01]
  }
}

"""Compare doing nothing, time-shifting and region-shifting a deferrable batch job.

Scores each option with two carbon signals (hourly average and hourly marginal intensity)
and with cost, so you can see where the signals and the cost disagree.
Standard library only.  Usage: python3 shift_options.py shift-inputs.json
"""
import json
import sys


def window_kg(series, start, hours, kwh_per_hour):
    return sum(series[(start + h) % 24] for h in range(hours)) * kwh_per_hour / 1000


def main(path):
    with open(path, encoding="utf-8") as fh:
        cfg = json.load(fh)
    job, home, alt = cfg["job"], cfg["home"], cfg["alternative"]
    per_hour = job["facility_kwh"] / job["hours"]
    first = job["earliest_start_hour"]
    slack = job["must_finish_within_hours"] - job["hours"]
    starts = [(first + s) % 24 for s in range(slack + 1)]
    avg, mar = home["average_gco2e_per_kwh"], home["marginal_gco2e_per_kwh"]
    best_avg = min(starts, key=lambda s: window_kg(avg, s, job["hours"], per_hour))
    best_mar = min(starts, key=lambda s: window_kg(mar, s, job["hours"], per_hour))
    rows = []
    for label, start in (("run now", first), ("shift: best average window", best_avg),
                         ("shift: best marginal window", best_mar)):
        rows.append((label, f"{start:02d}:00 home",
                     window_kg(avg, start, job["hours"], per_hour),
                     window_kg(mar, start, job["hours"], per_hour), job["compute_cost"]))
    net_lo, net_hi = (alt["data_moved_gb"] * k for k in alt["network_kwh_per_gb"])
    alt_kg = job["facility_kwh"] * alt["annual_average_gco2e_per_kwh"] / 1000
    grid_mean = sum(avg) / 24  # assumption: network energy at the home grid's daily mean
    net_kg = (net_lo * grid_mean / 1000, net_hi * grid_mean / 1000)
    alt_cost = (job["compute_cost"] * alt["compute_price_factor"]
                + alt["data_moved_gb"] * alt["egress_price_per_gb"])
    print(f"Options for {job['name']} ({job['facility_kwh']} kWh, {job['hours']} h,"
          f" earliest {first:02d}:00, within {job['must_finish_within_hours']} h)")
    print(f"  {'option':<30}{'where':<15}{'avg kg':>8}{'marg kg':>9}{'cost':>8}")
    for label, where, a, m, cost in rows:
        print(f"  {label:<30}{where:<15}{a:8.2f}{m:9.2f}{cost:8.2f}")
    if alt["residency_allowed"]:
        print(f"  {'shift: other region':<30}{alt['region']:<15}"
              f"{alt_kg + net_kg[0]:8.2f}{'n/a':>9}{alt_cost:8.2f}")
        print(f"    annual-average intensity; network adds {net_kg[0]:.2f}"
              f" to {net_kg[1]:.2f} kg")
        worst_kg = alt_kg + net_kg[1]
        extra = alt_cost - job["compute_cost"]
        # Price the move against run-now AND against the best free option (a time shift).
        gains = (rows[0][2] - worst_kg, min(r[2] for r in rows) - worst_kg)
        per_kg = [f"{extra / g:.2f}" if g > 0 else "no gain" for g in gains]
        print(f"    extra cost per kg avoided (worst network): {per_kg[0]} vs run now,"
              f" {per_kg[1]} vs best shift")
    else:
        print("  shift: other region          not allowed (data residency)")
    base_a, base_m = rows[0][2], rows[0][3]
    for label, _, a, m, _ in rows[1:]:
        print(f"  {label}: {100 * (base_a - a) / base_a:.0f}% less by average signal,"
              f" {100 * (base_m - m) / base_m:.0f}% less by marginal signal")
    if best_avg != best_mar:
        print("WARNING: the signals pick different windows; record the policy's signal")
    return 0


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("usage: python3 shift_options.py <shift-inputs.json>")
    sys.exit(main(sys.argv[1]))

$ python3 shift_options.py shift-inputs.json
Options for nightly-etl (40.0 kWh, 3 h, earliest 18:00, within 24 h)
  option                        where            avg kg  marg kg    cost
  run now                       18:00 home        14.00    20.80   60.00
  shift: best average window    12:00 home         5.00    17.60   60.00
  shift: best marginal window   00:00 home        12.07    15.20   60.00
  shift: other region           europe-north1      1.34      n/a   75.20
    annual-average intensity; network adds 0.14 to 1.35 kg
    extra cost per kg avoided (worst network): 1.33 vs run now, 6.21 vs best shift
  shift: best average window: 64% less by average signal, 15% less by marginal signal
  shift: best marginal window: 14% less by average signal, 27% less by marginal signal
WARNING: the signals pick different windows; record the policy's signal

1. Save both files and run the script. 2. Set residency_allowed to false and run again. 3. Replace the series with a day of real data for your region, and record which signal your policy uses.

Expected output. Step 1 as shown: the average signal says “wait until noon” (64% less), the marginal signal “run at midnight” (27% less), because the illustrative marginal series stays high at noon while the average dips for solar. The region move cuts most but costs 6.21 currency units per kg beyond the free time shift (not 1.33 against running now); compare that with any internal carbon price. Step 2 prints “not allowed (data residency)”. Validation: every option finishes within the 24-hour window. Troubleshooting: IndexError means a series without 24 values. Teardown: delete the files.

Objective: turn hardware energy counters into kWh and gCO2e per namespace, and allocate idle power. Prerequisites: a non-production cluster whose nodes expose RAPL or hwmon sensors, Helm 3, Prometheus scraping the exporter, and cluster-admin rights. Risks: the Kepler DaemonSet’s documented chart values set hostPID: true and privileged: true; review them with your security team.^[52] The step-1 debug pod shares the node’s namespaces and root filesystem and needs rights to create such pods;^[53] step 3 is the lower-privilege check.^[52]

Example status: syntax-checked with bash -n; not executed (no cluster with power sensors).

#!/usr/bin/env bash
set -euo pipefail
NODE="${NODE:-worker-1}"                 # any node name from: kubectl get nodes
# Chart 0.11.1 is the install guide's example; the latest Kepler release is v0.12.0
# (2026-09-22). Pin the chart you reviewed, and the image tag in your values file.
CHART_VERSION="${CHART_VERSION:-0.11.1}"
# 1. Does the node expose RAPL zones? An empty listing means nothing real to measure.
#    The debug pod shares the node's IPC, network and PID namespaces and mounts its root
#    filesystem at /host. Delete it afterwards: kubectl get pods | grep node-debugger
kubectl debug "node/${NODE}" -it --image=busybox:1.36 -- ls /host/sys/class/powercap
# 2. Install the exporter from the project's OCI chart.
helm install kepler oci://quay.io/sustainable_computing_io/charts/kepler \
  --version "${CHART_VERSION}" --namespace kepler --create-namespace
kubectl get daemonset,pods -n kepler   # every node should run one Kepler pod
# 3. Lower-privilege check once Kepler runs (use a pod name printed by step 2):
#    kubectl exec -n kepler -it KEPLER_POD -- ls /sys/class/powercap/intel-rapl

Then run these queries in Prometheus (metric names from Kepler 0.10 and later; filter on one zone, because zones overlap and “should not be summed”^[54]):

Example status: not executed or parsed (no cluster).

# kWh per namespace over the last 24 hours (CPU package zone only)
sum by (pod_namespace) (
  increase(kepler_pod_cpu_joules_total{zone="package"}[24h])
) / 3.6e6

# Node energy and its idle part over the same window, in kWh
sum(increase(kepler_node_cpu_joules_total{zone="package"}[24h])) / 3.6e6
sum(increase(kepler_node_cpu_idle_joules_total{zone="package"}[24h])) / 3.6e6

Steps. (1) Run the script. (2) After a day of scraping, run the queries. (3) Allocate idle energy to namespaces by share of CPU requests, since SCI counts hardware “reserved or provisioned”.^[7] (4) Multiply by PUE and grid intensity. Expected output: kWh per namespace. Pod energy covers active power only (“no more idle/dynamic for workloads” since 0.10),^[39] so the idle query shows what is left to allocate. Validation: namespaces plus idle never exceed the node total for the same zone; the remainder is host processes, allocated like idle. Troubleshooting: no zone values means no sensors (a “fake CPU meter” exists for development only);^[52] doubled totals mean summed zones. Teardown: helm uninstall kepler -n kepler, kubectl delete namespace kepler, and delete the node-debugger pod. Limits: RAPL zones cover only what the hardware exposes;^[54] add PUE, other components and embodied carbon separately.

In 2020 Google described shifting “non-urgent compute tasks” to low-carbon hours using day-ahead forecasts.^[10] Context and method: internal jobs that “tolerate delays as long as their work gets completed within 24 hours” run under Virtual Capacity Curves, which “impose hourly limits on resources available to temporally flexible workloads while preserving overall daily capacity”; user-facing services and customers’ VMs were not shaped. Measured result: in a randomised two-month trial on one campus in 2021, average cluster power fell 1–2% in the highest-carbon hours; about 10% of clusters a day could not be shaped (too full, or short of data).^[55] Lesson: shifting needs a large pool of deferrable work and capacity limits as the control. Measure it against a control group: multiplying power by intensity “does not necessarily yield the correct result”.^[55]

Since Windows 11 version 22H2, Windows Update schedules installations when a device is plugged in, turned on, connected and “regional carbon intensity data is available”; users can bypass it. Microsoft says the timing “might result in lower-carbon emissions” but publishes no saving.^[56] What a fleet owner could measure (this page’s suggestion): devices where the feature runs, installs users bypass, and patch-compliance time, which must not slip. Lesson: demand shifting needs no cloud; any fleet of deferrable tasks qualifies (EndpointOps).

Google measured a median Gemini Apps text prompt at 0.24 Wh, 0.03 gCO2e (market-based) and 0.26 mL of water, counting accelerators, hosts, idle capacity and overhead; a narrower boundary on more highly utilised machines gave 0.10 Wh. Measured change: on the comprehensive boundary, emissions per median prompt fell 44-fold from May 2024 to May 2025: 33-fold less energy from software, and a 1.4-fold lower market-based intensity from location and clean-energy procurement.^[24] Lesson: compare boundaries and methods before comparing AI footprints, and split any reduction into energy and factor; the figures are Google’s own.

Utilisation and method coverage lead; emissions and SCI lag. Report totals and SCI together.

1. Method gap. At Google’s 2024 data-centre factors, 1 MWh is 345 kg location-based and 94 kg market-based:^[24] a ratio of 3.7. A report that switches methods “cuts” 73% without one kilowatt-hour less.
2. Carbon per spend. A 30% commitment discount on unchanged usage raises kgCO2e per 1,000 currency units by 1 ÷ 0.7 − 1 = 43%. So set carbon targets per unit of work, not per unit of money.

Energy telemetry from people’s laptops can be personal data (PrivacyOps).

Where carbon and cost diverge. Forrester quotes Werner Vogels at AWS re:Invent 2023: “Cost is a close proxy for sustainability”.^[1] It usually is: usage optimisation cuts both.^[2] GreenOps earns its keep where it is not:

The cost of GreenOps itself is mostly people time; buy precision only where a decision needs it.

• Monthly reconciliation of estimates against provider exports, with each gap explained (boundary, method, version).
• Re-baseline whenever a provider changes its methodology version; AWS and Google can restate history.^[32][22]
• Risk indicators (this Atlas’s thresholds): any untagged figure; a provider month not exported within ten days of publication; an unexplained month-on-month change above 20%; a region-policy exception open for more than 90 days.

An illustrative scenario: the September ledger shows market-based emissions up 38% while the bill rose 4%.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 20, "rankSpacing": 32}}}%%
flowchart TB
  S["Emissions up 38%, cost up 4%"] --> V{{"Model version changed?"}}
  V -- "Yes" --> RB["Re-export both months on one version"]
  V -- "No" --> MT{{"Method or boundary changed?"}}
  MT -- "Yes" --> FX["Restate on one method"]
  MT -- "No" --> RG{{"Region mix changed?"}}
  RG -- "Yes" --> RD["Review placement"]
  RG -- "No" --> UG["Real growth: check SCI per unit"]
  RB --> C["Explain in the monthly review"]
  FX --> C
  RD --> C
  UG --> C
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class S risk
  class V,MT,RG decision
  class RB,FX,RD,UG,C core

1. Version: compare carbon_model_version (Google) or the methodology version (AWS); providers restate history.^[44][32]
2. Method and boundary: was the dashboard switched between methods (the Customer Carbon Footprint Tool defaulted to market-based in 2025;^[13] the AWS Sustainability console shows both and their gap as “estimated emissions savings”^[58]), or did new Scope 3 categories arrive?
3. Region mix: a cheaper region can be dirtier, so cost can fall while emissions rise.
4. Growth: only now compare SCI per unit; flat intensity means emissions grew with the business.
5. Record the cause and restated figures; never overwrite the original export.

Invest in GreenOps when IT is material to a corporate climate target; customers or regulators ask for workload-level data; you run data centres, large AI workloads or device fleets; or region, refresh and architecture decisions are pending in which carbon could change the answer.

Keep it light when the footprint is small and no decision depends on precision (a provider dashboard, one region rule and an annual review suffice), when the uncertainty is larger than the difference between options, or when carbon would be traded against residency or reliability without an explicit decision. Avoid it entirely as a label for offset purchases.

%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 22, "rankSpacing": 28}}}%%
flowchart TB
  S["Workload with a carbon question"] --> Q0{{"Material, with a decision pending?"}}
  Q0 -- "No" --> A0["Report annually; no project"]
  Q0 -- "Yes" --> Q1{{"Idle or oversized?"}}
  Q1 -- "Yes" --> A1["Rightsize, consolidate, schedule off-hours"]
  Q1 -- "No" --> Q2{{"Can it wait hours?"}}
  Q2 -- "Yes" --> A2["Time-shift with a deadline guard"]
  Q2 -- "No" --> Q3{{"Can it move region?"}}
  Q3 -- "Yes, within rules" --> A3["Region ADR: both methods and cost per kg"]
  Q3 -- "No" --> Q4{{"Owned hardware due for renewal?"}}
  Q4 -- "Yes" --> A4["Refresh or extend: payback in both units"]
  Q4 -- "No" --> A5["Efficiency work in code and data"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class S neutral
  class Q0,Q1,Q2,Q3,Q4 decision
  class A0,A1,A2,A3,A4,A5 core

These levels are this Atlas’s model; they echo, but are not, the FinOps Foundation’s Crawl, Walk and Run descriptions.^[2]

• Provider carbon exports switched on for every account, project and subscription; first month stored.
• A method note: location- or market-based for which purpose, signal, boundary, factor sources.
• SCI with a range for the three largest services; the most sensitive input named.

• Carbon line in the ADR: baseline and proposal by the same method, with ranges.
• Residency, latency, SLO and cost checked before carbon; trade-offs recorded.

• Exports loaded; model versions recorded; gaps against estimates explained.
• Every figure in a deck tagged with method, scope and boundary.
• No engineering reduction claimed from certificates, PPAs or offsets; market-based changes labelled.

GREENOPS METHOD NOTE — <organisation>                 Owner: <name>   Review: annual
Purposes:   Engineering decisions -> location-based, SCI (ISO/IEC 21031:2024).
            Corporate inventory   -> location- and market-based (GHG Protocol dual).
Signal:     Scheduling uses <average | marginal> intensity from <provider>.
Boundary:   Compute, storage, network (flagged), PUE, embodied share; excluded: <list>.
Factors:    Grid <source, year, granularity>; embodied <LCA source or range>.
Ranges:     Every estimate low / central / high; decide only beyond the range.
Versions:   Provider model versions stored; restate on change, never overwrite.

CARBON — ADR-<nnn> <title>                                   Date: <YYYY-MM-DD>
Functional unit: <per 1,000 requests | per job | per user>
Baseline SCI:  <low> / <central> / <high>   Method: <location-based, annual 2025>
Proposal SCI:  <low> / <central> / <high>   Same method and boundary: <yes/no>
Difference beyond the range? <yes/no>       Cost change: <+/- amount>
Conflicts: residency <..> latency <..> SLO <..> commitments <..>
Decision and owner: <...>         Verify in ledger on: <month>

Is GreenOps just FinOps? Largely overlapping, not identical: the FinOps Foundation treats sustainability as one of its capabilities.^[2] The difference is the accounting and the cases where carbon and cost diverge.

Our provider says our cloud use is carbon neutral. Do we still need this? Yes, if you set targets on physical emissions. Provider claims rest on market instruments; SCI excludes them.^[7] Ask for the location-based series.

Which number do we report? For corporate inventories, where contractual instruments exist, both methods (dual reporting).^[6] For targets, the method the company declares.^[6] For engineering decisions, location-based.

Is the cloud greener than our data centre? Often more efficient (PUE 1.09 against a 1.54 survey average^[29]), but moving “will not automatically reduce your emissions”:^[20] utilisation, region and architecture decide.

What about water? AWS now reports annual water withdrawals; the EU requires WUE from large data centres; Google reports 0.26 mL per median Gemini prompt.^[32][12][24] Track it where cooling water is scarce.

• Hourly matching may reshape market-based accounting before the joint GHG Protocol–ISO standard (Q4 2028, as of October 2026).^[26] Established today: dual reporting. Emerging: hourly CFE% such as Google’s.^[21]
• Embodied transparency. Configuration-level LCAs from suppliers are the main gap (ProcurementOps).^[28]
• Speculative: real-time schedulers trading carbon, price and latency across providers; given the limited gains from shifting,^[37] treat large savings claims with care.

• Day 1 (beginner): read to reading the numbers; run Lab 1.
• Week 1 (practitioner): the GSF Green Software Practitioner course^[59] and the SCI specification;^[7] Labs 2 and 3.
• Day 30 (practitioner, leader or architect): the method note and a ledger for one product, reconciled with provider data; leaders add the judgement call and the FinOps Sustainability capability.^[2]
• Specialise: Let’s Wait Awhile and On the Limitations of Carbon-Aware … Shifting for research;^[11][37] KubernetesOps and ObservabilityOps for measurement; FinOps, FinOps for AI and ComplianceOps for money and disclosure.
• Portfolio project: one verified reduction, recorded in an ADR with both methods.

Situation (illustrative). An owned data centre (PUE 1.5) runs 40 five-year-old servers, each using an assumed 2,600 kWh a year. Option A: replace them with 20 new servers, assuming a 2:1 consolidation from a benchmark; each uses about 1,973 kWh a year, Dell’s R760 light-medium figure, and embodies 420–1,260 kg (Dell-derived, up to three times for richer configurations).^[28] Option B: extend the old servers by two years.

The attractive choice and why it can be wrong. “New hardware is efficient” wins easily on a fossil-heavy grid. On a clean grid the payback approaches the new servers’ four-to-six-year life, and without consolidation (1:1) it becomes 15–45 years: extending wins. Money diverges again: at an illustrative 0.15 per kWh the energy saving is about 14,500 a year against 240,000 of capital (16.5 years); avoided support contracts of an assumed 1,500 per old server cut that to about 3.2 years.

Recommendation. Benchmark the consolidation ratio first: it is the largest uncertainty. On a high-carbon grid with real consolidation, refresh; on a clean grid, extend unless consolidation is large or support costs force the change, and pass old hardware on for reuse. Record both paybacks in the ADR.

After this page you should be able to explain the three terms and three levers; distinguish location-, market-based, average and marginal figures; estimate SCI with a range; identify where carbon and cost diverge; and decide which lever to pull first.

1. A team reports a 70% cut after switching its dashboard from location-based to market-based. What do you ask?

2. A job uses 50 kWh of IT energy at a PUE of 1.2 on a 300 gCO2e/kWh grid, with an embodied share of 2 kg, and serves 100,000 requests. What is its SCI per 1,000 requests?

3. Your company’s climate target uses market-based Scope 2; it signs a PPA for a new wind farm. Can the platform team report the PPA as a cut in its services’ SCI?

4. For a batch job the average signal picks noon and the marginal signal picks midnight. What do you do?

5. After moving a service to a clean region, its embodied share rose from 35% to 83%. Is that a problem?

GreenOps is a young name for an old discipline (energy efficiency) joined to a newer one (carbon accounting). The label may fade; the work will not, because carbon figures from providers, regulators and customers keep disagreeing for reasons that can be explained. Teams that do this well do not have the most precise figure; they know each figure’s method, carry ranges, and act first where carbon and cost agree.

Where the two diverge, make an explicit, recorded decision rather than accepting a dashboard default.

Footnotes give source and check dates. Claim-level notes are in research/greenops-ledger.md.

Changelog. 2026-10-17, r0: first draft (research, ledger, labs executed, six diagrams); not yet independently reviewed. 2026-10-17, r1: revised after independent review (reviews/greenops-r1.md): offsets separated from contracts; GHG Protocol timeline; residency inheritance; Lab 2 pricing; IEA update; acronyms. 2026-10-17, r2: revised after independent scoring (reviews/greenops-score.md): market-based figures’ legitimate uses; measured results in cases; AWS and Azure exports; embodied low bound 840 kg; learning cadence; diagrams shortened. 2026-10-18, post-score polish: AI boundary gap’s two causes; Google’s “low carbon” rule; AWS service permissions; PromQL status; Figure 1’s exclusions boxed (reviews/greenops-polish.md).