Every sustainability guide tells you to measure your Kubernetes cluster's carbon footprint. The tools that do it are either enterprise SaaS priced like enterprise SaaS, or a pile of open-source components you have to assemble yourself. Either way, the number that comes out is an estimate, and most tools never label it as one.
KEIT, our Kubernetes Emissions Insights Tool, is what we built and open-sourced in response. It combines six existing tools into one live Grafana view of your cluster's emissions. The figures are labelled as estimates, and the dashboards are built for acting on them, because you do not need a perfect number to start cutting emissions.
Six tools, one estimate
KEIT reuses existing tools, one for each term of the emissions equation.
| Component | What it contributes |
|---|---|
| Kepler | Energy use of the running software, per container, pod, and node |
| ElectricityMaps (via the grid-intensity-go exporter) | The carbon intensity of the electricity in your grid zone, live |
| Boavizta API | The embodied emissions of the hardware underneath |
| Metrics Server | Resource utilisation |
| Prometheus | Collects and stores all of it |
| Grafana | Turns it into something a team looks at |
Energy times grid intensity gives operational emissions, and Boavizta adds the hardware's embodied share. Together they make an SCI-style figure per workload, named after the Software Carbon Intensity approach to software emissions. KEIT's comparison dashboard calls it "KEIT-computed SCI".
Installation takes seven Helm steps, and configuration needs only three things: an ElectricityMaps API token (a free tier exists), your grid zone code, and your datacenter's PUE. You set the zone once, and the repo says plainly that it is not picked up dynamically yet.
Composing these tools was a deliberate choice. Each one is the community's standard tool for its term, and KEIT supplies the glue, the dashboards, and the opinions.
How the code labels uncertainty
Four artifacts from the repo:
- The README's first sentence says KEIT "estimates the carbon emissions of a Kubernetes cluster". It doesn't claim to measure or track them.
- The Boavizta exporter's data model stores the min, max, and warnings that come with every embodied-emissions figure, along with the value itself.
- The tool reports its own staleness. The metric
keit_scaleway_data_lag_daysexists only to say how old the data is. - The Scaleway exporter's README gives its limitations a section of their own, titled "Granularity caveats, read these".
An estimate with its uncertainty attached is more useful than a precise-looking number with no error bars. Deciding which workload, region, or fix to tackle first only needs the shape to be right.
Managed Kubernetes and the Scaleway exporter
On managed Kubernetes you usually cannot measure power at all. The nodes are VMs, and VMs expose no hardware power interface (RAPL), so energy tools have to model power instead of measuring it. Right now the community's standard exporter cannot even do that everywhere.
If you run managed Kubernetes, read this first
Kepler v0.10+ dropped the metric these dashboards rely on and does not support VMs right now. On EKS, GKE, AKS, or Kapsule, stay on the older chart (0.6.1, binary 0.8.0) until upstream restores VM support, tracked in Kepler issue #2363.
For clusters on Scaleway, KEIT ships a way around the problem: a Prometheus exporter for Scaleway's Environmental Footprint API. Instead of modelling power from inside a VM, it pulls the provider's own ADEME-based footprint data, carbon and water for any Scaleway service, hourly over a trailing 14-day window. It exposes that data as metrics such as keit_scaleway_co2_kg, broken down by region, zone, and SKU.
Its README documents the limits with the same candour:
- A SKU is a resource type, not an instance, so provider data alone cannot attribute emissions to individual pods. You join it with Kubernetes metadata and pick an attribution rule, in a recording rule you control.
- The data lags. That is why the staleness metric exists and why the exporter reads a 14-day window. Alert when the lag crosses your threshold.
- Coverage is uneven. Some regions report water usage as zero, and the managed control plane shows up as a small flat figure.
Scaleway is one of the few providers that publish environmental accounting at API level at all, and any real dataset has limits like these.
Four dashboards for acting on the numbers
KEIT ships four dashboards. You can import them into any Grafana 9+, or apply them as Grafana Operator CRDs if your dashboards live in GitOps with the rest of your platform:
| Dashboard | What it is for |
|---|---|
keit-scaleway-footprint | The vendor's view: CO₂ and water by project, region, and SKU, with daily trends |
keit-scaleway-vs-sci-comparison | KEIT-computed SCI next to the provider's bundled figure, showing the gap and letting you decompose it |
keit-scaleway-hotspots | Top projects and SKUs, regression detection, and the regional-grid-effect heatmap, which shows the same machine type producing different carbon in different zones |
keit-rightsizing | Overprovisioned pods, underprovisioned pods, pods missing requests, and cumulative energy over seven days |
Two legitimate ways of computing your footprint will not agree. The comparison dashboard shows the gap between them, which tells you what each number does and does not cover. The rightsizing dashboard ties carbon to the bill: an overprovisioned pod wastes money and watts at the same time, so fixing it usually lowers cost and carbon together.
Together the dashboards support a loop: see the footprint, compare the methods, find a hotspot, fix it, watch the trend, then find the next one.
Where it stands, and how to start
KEIT is young, and the repo is open about its gaps. Bare metal is the proven path, AWS EKS is adapted, and Azure support is in progress, with GCP named as a future target. The grid zone is configured once instead of detected. Prometheus needs its out-of-order window widened to accept the lagging provider data, and the Helm chart is at v0.2.0. We have shown the dashboards publicly, most recently at Green IO Amsterdam 2026, and everything they need ships in the repo.
Getting started takes an afternoon: install with Helm, get the free ElectricityMaps token, set your zone and PUE, import one dashboard, and look for your first hotspot.
Try it, or talk to us
KEIT is open source under Apache 2.0: run it, break it, file issues.
If you would rather run the loop with a team that has done it before, that is work we do, using the same tool we run ourselves.