Carbon as a first-class signal: Bringing software carbon intensity to OpenTelemetry

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.

Figure 1 – Me speaking at Observability Summit EU

The missing signal in observability

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.

We need to move beyond collecting isolated measurements toward understanding the carbon impact of the work our systems perform.

Understanding Software Carbon Intensity

The Software Carbon Intensity specification from the Green Software Foundation provides a methodology for measuring the carbon emissions associated with software.

Rather than considering total emissions alone, SCI relates emissions to a functional unit of software activity.

The formula is:

Where:

E (Energy): Energy consumed by the software.

I (Carbon intensity): Carbon emissions associated with the electricity consumed per unit of energy.

M (Embodied emissions): Emissions associated with the hardware used by the software, allocated to the activity being measured.

R (Functional unit): The unit of work performed, such as a request, transaction, or user.

The functional unit is particularly important because it allows us to evaluate carbon efficiency in relation to useful work.

Imagine two versions of an application.

Version A produces 100 kg CO₂e while processing one million transactions. Version B produces 110 kg CO₂e while processing two million transactions.

Although Version B produces more emissions overall, its emissions per transaction are lower:

Version A

Version B

Total emissions

100 kg CO₂e

110 kg CO₂e

Transactions

1 million

2 million

SCI per transaction

0.0001 kg CO₂e

0.000055 kg CO₂e

Version B has a lower carbon intensity per transaction, despite its higher total emissions.

Figure 2: Software Carbon Intensity (SCI)

This distinction matters when evaluating software optimizations. Reducing total energy consumption and improving efficiency per unit of work are related, but they are not interchangeable objectives.

SCI gives engineers a structured way to examine both.

Why OpenTelemetry matters

OpenTelemetry has helped the cloud-native community establish a common language for collecting and exchanging telemetry.

Through its semantic conventions, OpenTelemetry defines how attributes and measurements can be represented consistently across different systems, programming languages, and infrastructure environments.

This same approach could help address a significant challenge in software sustainability: making carbon-related information understandable and interoperable.

Today, different tools may expose energy consumption, electricity carbon intensity, or estimated emissions using different names, units, and levels of granularity.

Even when the underlying measurements are available, connecting them to a particular Kubernetes workload, service, or operation is not straightforward.

The SCI for OpenTelemetry initiative explores how SCI concepts could be represented using OpenTelemetry semantic conventions.

The goal is not to introduce carbon as a replacement for existing observability signals. Instead, it is to establish a consistent way to describe carbon-related information alongside the operational context engineers already collect.

For example, a shared vocabulary could help describe energy consumption, carbon intensity, embodied emissions, and the functional unit used for an SCI calculation.

This would make it easier for different implementations to exchange and interpret sustainability information without relying on tool-specific definitions.

Importantly, this work is still evolving. The proposed conventions should not be confused with finalized or officially adopted OpenTelemetry semantic conventions.

The difficult part: attribution and context

One of the most important questions in bringing SCI to OpenTelemetry is how carbon-related information should be attributed to software.

In cloud-native environments, infrastructure resources are frequently shared. Multiple workloads can run on the same node, applications can scale dynamically, and services may depend on infrastructure distributed across different locations.

Measuring the energy consumption of a physical machine does not automatically tell us how much energy a particular application consumes.

Similarly, knowing the carbon intensity of electricity in a region does not directly establish the emissions attributable to an individual service.

The SCI for OpenTelemetry community has been examining these questions through a series of discussions focused on scope, use cases, and the information needed to support consistent calculations.

Several important themes have emerged.

Attribution rather than measurement alone. The challenge is not necessarily to invent new ways to measure energy. It is to establish how existing measurements and estimates can be associated with the software responsible for a particular activity.

Support for modeled and estimated values. Not every environment provides direct energy measurements. Some values must be estimated or derived from models. A useful specification needs to account for these differences rather than assume every measurement is directly observed.

Provenance and transparency. Engineers need to understand where carbon-related values originate, how they were calculated, and what assumptions were involved. Without this information, comparisons can be misleading.

Clear boundaries and units of work. SCI calculations depend on what is included in the measurement and which functional unit is selected. These choices need to be explicit for results to be meaningful.

These are not simply naming problems. They influence how carbon information can be interpreted, compared, and used in practice.

From scope to semantic conventions: where the work stands today

At the time of writing, the first phase of the SCI for OpenTelemetry Assembly, focused on scope and use cases, has concluded with community consensus.

The objective was to establish which problems the proposed semantic conventions should address first, before defining the attributes, metrics, and structures needed to represent SCI in OpenTelemetry.

The community agreed on three use cases, in order of priority.

1. Helping engineers understand the impact of their changes

The highest priority is enabling application developers, platform engineers, and SREs to determine whether a release, configuration change, or architectural decision has reduced energy consumption or carbon emissions for the same amount of work.

Just as importantly, engineers should be able to identify which components are responsible when consumption increases.

This requires attributing energy and emissions to identifiable software entities, using consistent measurement windows and explicitly defined functional units.

2. Comparing carbon impact across services and providers

The second use case addresses comparisons between infrastructure providers, services, and migration options.

However, the Assembly recognized an important limitation: simply declaring a functional unit does not guarantee that two systems perform equivalent work.

Meaningful comparisons require clearly documented measurement boundaries, calculation methods, and functional units. Fully standardized comparisons would also require common workloads and testing procedures, which semantic conventions alone cannot provide.

3. Supporting automated carbon-aware decisions

The third use case explores how schedulers, autoscalers, and workload-placement systems could use carbon-related information to make operational decisions.

Unlike retrospective measurements, automated decisions often require timely information. This may involve forecasts, estimates, or modeled values rather than direct measurements.

The consensus emphasizes that these distinctions must remain visible. A forecast should not be presented as equivalent to a directly measured value.

What these decisions mean for the next phases

A common requirement emerged across all three use cases: carbon-related telemetry must clearly communicate its boundaries, calculation method, functional unit, and the nature of the value being reported.

This includes distinguishing operational from embodied emissions, identifying estimates and forecasts, and making the completeness of a measurement explicit.

These decisions provide a foundation for the next stages of the Assembly, which will address the SCI namespace and the representation of operational energy, embodied emissions, and functional units.

The goal is to develop proposed OpenTelemetry semantic conventions that can be reviewed and refined by the OpenTelemetry community, rather than introduce another incompatible way of representing sustainability information.

Community participation and diversity

Beyond the technical outcomes, the first phase also brought together participants from different backgrounds, organizations, and areas of expertise. The participation metrics and diversity data reflect the collaborative nature of the Assembly, connecting perspectives from software sustainability, observability, and cloud-native engineering. This diversity matters because defining a common standard requires more than technical agreement: it requires input from the people who will eventually implement, maintain, and use it across different environments.

Figure 3: Donut chart showing 65% (24)of invited participants took part across Discovery, Deliberate, and Decide phases, while 35% (13)did not.

Figure 4: Pie chart detailing participant diversity: 11 Enterprise/Product Engineering, 9 Observability/Performance Vendors, 7 Open Source/Community, 5 Consulting/IT Services, 4 Universities, and 1 Industry Research Lab.

The Phase 1 consensus document is publicly available and documents the agreed priorities and requirements.

Get involved in the next phases

The SCI for OpenTelemetry Assembly brings together engineers, sustainability practitioners, and observability contributors to help define how carbon information can be represented consistently.

Participation is not limited to Green Software Foundation members. The Assembly welcomes expertise in OpenTelemetry, Kubernetes, energy measurement, software sustainability, and cloud-native infrastructure.

The work is primarily asynchronous, allowing participants to contribute through structured discussions and consensus-building without attending mandatory meetings.

At the time of writing, applications for the current Assembly have closed, but interested contributors can join the waitlist through the Green Software Foundation to express interest in available places or future opportunities.

The SCI for OpenTelemetry GitHub repository also provides access to the ongoing work and published materials.

For cloud-native practitioners, this is an opportunity to help shape how sustainability information becomes part of the operational telemetry we already use.

From carbon measurements to engineering decisions

The long-term value of bringing carbon information into observability is not simply another dashboard.

It is the ability to consider carbon alongside the operational signals engineers already use when evaluating systems.

For example, consider a team optimizing a Kubernetes application. They might reduce CPU utilization, adjust resource requests, introduce autoscaling, or change how workloads are scheduled.

These changes can influence performance, infrastructure cost, energy consumption, and carbon emissions in different ways.

A configuration that improves one dimension does not necessarily improve all the others.

Having carbon-related information available alongside existing telemetry could help engineers understand these relationships instead of relying on assumptions.

A practical approach involves three steps.

First, measure what is available. Use existing infrastructure and observability tools to collect energy-related measurements and the context needed to interpret them.

Second, connect carbon to operational information. Associate energy consumption and carbon estimates with workloads, resource utilization, and relevant software activity. Make the source and limitations of estimated values visible.

Third, use that information in engineering decisions. Evaluate whether changes to resource allocation, scheduling, application efficiency, or infrastructure utilization improve carbon efficiency without overlooking reliability and performance requirements.

This is also where GreenOps becomes relevant.

Just as FinOps helps organizations connect technical resource consumption with financial impact, GreenOps brings environmental impact into infrastructure and software operations.

Carbon-aware engineering does not require treating sustainability as a separate operational discipline. It means making environmental impact part of the information available when designing and operating cloud-native systems.

Figure 5: Electricity Maps

An opportunity for the cloud-native community

Standardizing sustainability-related telemetry requires collaboration across several communities.

Energy measurement projects, observability practitioners, sustainability specialists, and software engineers all approach the problem from different perspectives.

The SCI for OpenTelemetry initiative provides a place to connect those perspectives and work toward a shared representation.

For the OpenTelemetry community, the opportunity is to explore how existing telemetry concepts can support sustainability use cases without introducing unnecessary fragmentation.

For the broader CNCF ecosystem, it is an opportunity to make energy and carbon information more interoperable across cloud-native infrastructure and applications.

And for practitioners, the most valuable contribution may be sharing real-world requirements: which measurements are available, where attribution becomes difficult, which estimates are necessary, and what information is needed to make useful comparisons.

These practical experiences can help shape conventions that work beyond individual implementations.

Making carbon a first-class operational signal

Cloud-native observability has evolved because engineers need context to understand increasingly complex systems.

Carbon information presents a similar challenge.

Measuring energy consumption is useful. Estimating emissions is useful. But the real opportunity comes from connecting those measurements to software behavior and the decisions that shape it.

SCI provides a methodology for evaluating software carbon intensity. OpenTelemetry offers a common language for representing and exchanging operational information.

Bringing these approaches together could help make carbon another meaningful dimension of cloud-native system efficiency.

Not as a replacement for performance, cost, or reliability, but as additional context for making better engineering decisions.

SCI gives us a way to measure. OpenTelemetry gives us a common language. Carbon can become a first-class operational signal.