OpenTelemetry just moved sustainability from quarterly reports into the telemetry stream.
A CNCF blog post outlining the Software Carbon Intensity (SCI) work is blunt: the proposed semantic conventions cover raw energy measurements, carbon estimates, workload context, and — crucially — visibility into estimation limits. In practice that would allow traces, metrics, and resource attributes to carry not just "this pod used X CPU" but "this span consumed Y joules, estimated CO2e Z g, provenance A, and uncertainty ±B%." That's a big deal.
Why this matters: carbon is not a vanity metric you can bolt onto billing. If SCI becomes a stable set of OpenTelemetry conventions, platform agents, schedulers, and autoscalers will be able to use carbon signals the same way they use memory pressure or P95 latency. Placement decisions can consider grid intensity and estimated emissions, profiles for ML jobs can be compared by joules-per-example, and platform observability tools can show carbon hot spots alongside CPU and I/O.
The operational plumbing: from watts to deployment decisions
OpenTelemetry already provides metrics, resource attributes, and semantic conventions, but SCI fills the missing vocabulary for sustainability. Expect three concrete categories in the conventions:
- energy and power measurements (watts, joules), with source tags for PDUs, IPMI, RAPL, or cloud provider telemetry;
- carbon estimates and provenance (regional grid intensity, on-prem power mix, model used to estimate CO2e) together with explicit uncertainty bounds; and
- workload context tying estimates to spans, pod labels, or scheduler decisions so you can attribute emissions to teams, features, or jobs.
The devil is in provenance and uncertainty. Without provenance, vendors will slap opaque "green" scores on dashboards and call it a day. Without uncertainty, small differences will be spun into greenwashing. SCI's emphasis on visibility into estimation limits is the right call: operational signals must carry confidence metadata or they become a liability, not an axis for automation.
Control planes need to act on these signals. If a management plane such as Meshery adopts SCI conventions, it becomes a natural integration point: fleet-wide experiments that measure energy impact, policy-driven placement that trades latency for lower carbon, and configurable rollout strategies that prefer low-carbon windows.
This is overdue, and it will be messy
Platform teams have long wanted to influence placement with non-functional signals; carbon is the cleanest real-world test of that idea. But expect friction. Tuning for carbon will surface hard trade-offs — cost, latency, compliance, and risk — and teams will have different appetites. Also expect a proliferation of partial implementations: cloud providers shipping provider-specific energy attributes, container runtimes exposing RAPL-derived metrics differently, and third-party tools offering their own carbon estimates. That heterogeneity is exactly why a common semantic layer in OpenTelemetry is necessary.
One technical note: if you care about versions and schema stability, watch the OpenTelemetry metrics schema efforts and host-metrics components that introduced versioned metric names. SCI should align with OpenTelemetry's metric schema and resource attribute conventions so existing dashboards and alerting rules don't silently misinterpret units or provenance.
Final take: treat carbon like latency, not like compliance
Making carbon a first-class signal is the right call and long overdue. Platform engineers should start thinking in terms of operational signals, provenance, and bounds — not just pretty dashboards. In practice that will mean architecting pipelines to carry provenance, extending admission controllers and schedulers to accept carbon-aware policies, and expecting vendors to add yet another set of attributes to their telemetry. Within 12–18 months you will see schedulers offer a carbon preference knob and platform teams arguing whether 5% more latency is worth 20% less CO2e. Those debates will define modern SRE work just as much as error budgets once did.