Posted on October 15, 2026 by Diana Todea - CNCF Ambassador, Kepler maintainer, OpenTelemetry Documentation approver and Romanian Localization maintainer At Observability Summit Europe 2026 in Prague, I presented a keynote titled Carbon as a First-Class Signal: Designing a Standard for OpenTelemetry . The talk explored how Software Carbon Intensity (SCI) could become part of cloud-native observability through OpenTelemetry semantic conventions, and how the Green Software Foundation ‘s ongoing work aims to establish a common language for carbon-related telemetry. Cloud-native systems are designed to be observable.
We collect metrics, logs, and traces to understand how applications behave, identify performance bottlenecks, and make better decisions about infrastructure. We monitor CPU utilization, memory consumption, request latency, and resource allocation. Yet one important dimension of system efficiency is still largely missing from our operational view: carbon emissions. As sustainability becomes part of the conversation around cloud-native infrastructure, the challenge is no longer simply whether we can measure energy consumption or estimate carbon emissions.
It is whether we can connect that information to the workloads, services, and engineering decisions that influence it. This is where Software Carbon Intensity (SCI) and OpenTelemetry could help establish a common approach. The cloud-native ecosystem already has tools for collecting energy and infrastructure information. Projects such as Kepler help expose energy-related metrics from Kubernetes environments. Other tools provide information about infrastructure utilization, energy consumption, and the carbon intensity of electricity. However, collecting these measurements is only part of the challenge.
Consider a Kubernetes workload that consumes less energy after an optimization. Is the application actually more carbon-efficient? What if the workload processes twice as many requests? What if the electricity powering the infrastructure has a different carbon intensity? And how do we attribute shared infrastructure consumption to individual applications? Traditional observability helps us understand what a system is doing. Energy and carbon measurements introduce additional context, but without a consistent way to associate that information with software activity, comparisons become difficult.