Software Carbon Intensity in practice: from spec to dashboard

For years, "green software" meant good intentions and rough estimates. The Software Carbon Intensity (SCI) specification changed that by giving the industry a single, defensible formula: emissions per unit of useful work. It sounds simple. Implementing it on a live system is where the real work begins.

What SCI actually asks of you

SCI is a rate, not a total. It forces you to define a functional unit — a request, a user, a transaction — and then attribute energy, embodied hardware carbon and grid intensity to that unit. The discipline is in the attribution, not the arithmetic.

• Energy consumed by the software (E)
• Carbon intensity of the electricity (I)
• Embodied emissions of the hardware (M)
• A functional unit (R) that reflects real work

Measure the energy you can, model the rest

On most cloud platforms you cannot read a wattmeter. We combine platform-level power APIs, CPU/GPU utilisation telemetry and vendor coefficients to produce an energy figure that is consistent over time — which matters more than being perfect on day one. Consistency lets you prove a trend.

A number you can reproduce beats a number you can defend in theory. Start consistent, then get accurate.

From telemetry to a dashboard people trust

The final step is making the data legible. We pipe SCI per service into the same observability stack teams already watch, with clear baselines and thresholds. When an engineer can see the carbon cost of a deploy next to its latency, efficiency stops being someone else's job.

That is the whole point of the specification: to move green software from a slide in a sustainability deck to a metric on an engineering dashboard.