OpenTelemetry SCI Telemetry: Measuring Carbon per Workload

Teams can monitor request latency and CPU usage while still being unable to explain the carbon impact of a particular service or unit of work. OpenTelemetry Software Carbon Intensity (SCI) telemetry aims to connect energy, electricity carbon intensity, and hardware emissions to software workloads. This explainer covers how the measurement model fits observability, how to build a defensible estimate, and why the proposed conventions should not yet be treated as a stable OpenTelemetry standard.

Why Software Carbon Is Being Talked About

Cloud systems already produce substantial operational telemetry: request rates, resource use, errors, and latency. Sustainability reporting often lives somewhere else, in cloud invoices, energy dashboards, facility meters, or spreadsheets. That separation makes it difficult to answer engineering questions such as whether a release reduced emissions per transaction, whether a workload is consuming more energy because its traffic grew, or whether moving a batch job changed its carbon impact.

The Green Software Foundation’s Software Carbon Intensity specification provides a way to express emissions in relation to a functional unit of software work. OpenTelemetry provides shared APIs, SDKs, protocols, and conventions for describing and exporting telemetry. Bringing the ideas together could make carbon measurements easier to associate with services and operations using the observability systems teams already run.

A recent CNCF discussion of carbon as an observability signal describes this direction. The gap is real, but the conventions are still being developed: the SCI for OpenTelemetry project currently labels its work pre-draft and says its proposed conventions are not yet stable or ratified.

What Is OpenTelemetry SCI Telemetry?

SCI telemetry is the collection and exchange of measurements needed to calculate or interpret a Software Carbon Intensity score alongside software telemetry. It is not a separate carbon sensor or a finished OpenTelemetry signal. Instead, it connects data such as energy use, electricity carbon intensity, allocated hardware emissions, and a count of useful work to a service or workload.

The SCI method can be written as:

SCI = ((E x I) + M) / R

Here, E is energy consumed, I is the carbon intensity of that energy, M is the software’s allocated embodied emissions, and R is a functional unit such as a request, transaction, or processed record. If energy is measured in kWh and carbon intensity in gCO2e/kWh, E x I is operational emissions in gCO2e. M must use a compatible emissions unit, and the result is emissions per functional unit.

The OpenTelemetry project supplies the general telemetry framework, while its metrics specification defines how numeric measurements are recorded and exported. SCI-related names, units, and aggregation rules are a separate question. Until the proposal completes review, teams should describe their local metrics explicitly instead of presenting local names as official OpenTelemetry conventions.

The Problem It Solves: Connecting Facility Data to Workloads

Energy and carbon data alone do not identify which software activity caused a change. A facility meter can show that a cluster used more power, but may not distinguish an individual application from other tenants. A service’s CPU metric can indicate load, but CPU utilization is not itself an energy measurement and cannot be converted into emissions without a documented model and inputs.

There are four connected measurement problems:

1. Attribution: Shared servers, storage, and networking need an allocation method before their energy can be assigned to workloads.
2. Time and location: Electricity carbon intensity varies by grid region and time. The value used for a measurement period should correspond to where and when the energy was consumed.
3. Embodied emissions: Hardware manufacturing emissions are not normally emitted as a live application metric. They need a documented lifecycle estimate and an allocation over hardware use.
4. Meaningful output: Total emissions can rise as a service performs more work. A functional unit helps distinguish total impact from emissions per request or transaction.

OpenTelemetry can help correlate measurements with service resources and export them through a common pipeline. It cannot create accurate energy data, determine a fair allocation, or validate the assumptions in an SCI calculation. Those remain measurement and governance responsibilities.

How SCI Telemetry Works

A practical pipeline combines measurements from several sources, aligns them to a reporting interval, associates them with workloads, and calculates a rate for a defined unit of work.

Once each component has a common scope, the calculation is straightforward. The hard work is ensuring that energy, carbon intensity, embodied emissions, and work counts refer to compatible periods and boundaries. A score that combines whole-cluster energy with only one service’s requests, for example, will not represent that service’s intensity unless the cluster energy has first been allocated appropriately.

OpenTelemetry’s semantic conventions provide shared names and meanings for common telemetry fields. The SCI initiative intends to use that mechanism, but its repository explains that the conventions are not yet drafted or ratified. A team experimenting today should keep its metric names, units, source, estimation method, and schema version in its own documentation. It should also expect those names to change as the community work progresses.

For high-level service identity, resource attributes such as service.name and deployment environment can help group measurements. Use bounded dimensions such as service, region, and workload class. Avoid recording request IDs or user identifiers as metric attributes: they create high cardinality and may expose sensitive information. A trace can help investigate an individual slow or expensive operation, but aggregated metrics are usually the appropriate place to publish SCI rates.

The W3C Trace Context specification standardizes how request context can be propagated between services. It helps connect spans in a distributed trace, but it does not define carbon metrics or allocate shared energy to software workloads.

Components and Key Concepts

Energy measurement may come from hardware meters, platform telemetry, or an estimation model. Projects such as Kepler estimate energy consumption in Kubernetes environments. Such output is an input to an SCI calculation, not automatically a precise per-application energy reading; hardware coverage, workload attribution, and model uncertainty still matter.

Carbon intensity converts energy to operational emissions using a region- and time-relevant emissions factor. Record the source and temporal resolution, and do not silently substitute a national average for a regional value. If only an average estimate is available, mark it as such.

Embodied emissions account for emissions associated with producing hardware. A service rarely owns a physical server outright, so the estimate may be allocated by reserved capacity, utilization, or another documented method and amortized over a defined hardware lifetime. This is a modeled allocation, not a direct observation of emissions at request time.

Functional units make the result interpretable. “Per request” can be useful for an API, while a data pipeline may prefer “per million records processed.” Comparing scores requires the same meaning of work and comparable system boundaries. Changing the unit or workload scope can change the number without changing the software.

Telemetry pipelines transport and process the resulting measurements. The OpenTelemetry Collector pipeline guide explains the receiver, processor, and exporter model. A Collector can route a custom metric to a backend, but routing does not standardize its meaning or fix inaccurate inputs.

Real-World Use Cases

• Release comparison: Compare emissions per transaction before and after a code or infrastructure change, while checking that workload mix and measurement boundaries remained comparable.
• Capacity planning: Identify services whose energy use or emissions intensity rises faster than useful throughput, then investigate saturation, idle capacity, or inefficient processing.
• Regional scheduling: Evaluate whether moving flexible batch work changes emissions after accounting for both regional carbon intensity and the extra energy or network activity caused by the move.
• AI workload accounting: Track energy and output units for training or inference workloads to make model size, accelerator choice, batching, and utilization trade-offs visible.
• Sustainability reporting: Present a documented intensity metric alongside its source data, uncertainty, time window, and allocation method instead of publishing an unexplained single score.

These are decision-support uses, not proof that a metric alone reduces emissions. An improvement in emissions per request can coincide with higher total emissions if request volume grows. Teams should state whether they are optimizing absolute emissions, intensity, or both.

Getting Started: Calculate and Instrument a Local Estimate

Start with a narrow service and a fixed time window. Select a functional unit, collect energy and grid-intensity inputs for the same scope, decide how embodied emissions are allocated, and count the completed work. If one input is estimated, preserve that fact alongside the result. The following Python example uses only the standard library and calculates grams of CO2-equivalent per 1,000 requests:

def sci_gco2e_per_1000_requests(
    energy_kwh: float,
    carbon_intensity_gco2e_per_kwh: float,
    embodied_gco2e: float,
    requests: int,
) -> float:
    if min(energy_kwh, carbon_intensity_gco2e_per_kwh, embodied_gco2e) < 0:
        raise ValueError("SCI inputs cannot be negative")
    if requests <= 0:
        raise ValueError("requests must be greater than zero")

    total_gco2e = (
        energy_kwh * carbon_intensity_gco2e_per_kwh
        + embodied_gco2e
    )
    return total_gco2e / requests * 1_000


score = sci_gco2e_per_1000_requests(
    energy_kwh=2.4,
    carbon_intensity_gco2e_per_kwh=350,
    embodied_gco2e=80,
    requests=10_000,
)
print(f"{score:.1f} gCO2e per 1,000 requests")

Save it as sci_score.py and run:

python --version
python sci_score.py

The example produces 92.0 gCO2e per 1,000 requests. It demonstrates the arithmetic, not an energy-measurement method: the values are illustrative and must be replaced with measured or defensibly modeled inputs. Before exporting the result, record the measurement interval, region, service identity, functional unit, source and estimation quality of each component, and the allocation method. Use the OpenTelemetry SDK and a compatible backend to export the chosen custom metric; consult the OpenTelemetry documentation for language-specific setup. Do not copy proposed SCI attribute names from an evolving draft into production as though they were ratified.

Verify a pilot by reconciling its energy estimate against the source meter or platform data, checking that the work count covers the same time window, and reviewing the allocation rules with infrastructure owners. Compare like-for-like intervals and traffic mixes. If a number changes, the pipeline should make it possible to tell whether energy, carbon intensity, the workload, or the model changed.

Common Misconceptions

“OpenTelemetry already defines SCI metrics.” The OpenTelemetry framework supports numeric metrics, but the SCI-specific project is still pre-draft. Local metric names and units are not yet a shared, ratified convention.

“CPU utilization is the same as energy.” Utilization is a useful correlate, but energy depends on the hardware, power state, workload, and measurement model. Treating utilization as kWh without a validated model hides uncertainty.

“A lower SCI score always means lower total emissions.” SCI is a rate per functional unit. A service can become more efficient per request while total emissions rise because it serves more requests. Report the rate and absolute totals when both matter.

“Adding carbon attributes to traces gives exact per-request emissions.” A trace may identify a request path, but shared energy and lifecycle emissions are normally allocated across workloads. Distributing aggregate estimates to individual traces can imply a level of precision the data does not support.

Related Articles

• Green Software Development Practices
• OpenTelemetry Signals and Distributed Tracing Explained
• OpenTelemetry Collector Pipelines and Tail Sampling Explained
• Green Data Center Design

Changelog and Last Updated

Last updated: November 1. Initial publication.