CO₂ per deployment: the 5th DORA metric your engineering org is ignoring

The four DORA metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery — have become the standard language for engineering performance. They tell you how fast your team ships, how often it breaks, and how quickly it recovers. They do not tell you how clean the deployments are.

CO₂ per deployment is the 5th metric. It exists at the intersection of engineering performance and sustainability reporting, and it is the one metric that connects the work engineers do every day to the emissions numbers on a CSRD or SB 253 filing.

Why it belongs next to the other four

The four DORA metrics share a property: they are observable, attributable, and actionable. You can track them over time, identify which teams are improving, and intervene when they degrade. CO₂ per deployment has all three properties.

Metric                  Measures               Drives
──────────────────────────────────────────────────────────
Deployment Frequency    Shipping cadence        Delivery speed
Lead Time               Commit-to-deploy time   Pipeline efficiency
Change Failure Rate     Deploy quality          Test coverage
MTTR                    Recovery speed          On-call effectiveness
CO₂/deployment          Carbon efficiency       Green engineering
──────────────────────────────────────────────────────────
All five are: observable · attributable · improvable · trending

What makes CO₂/deployment distinct is that it catches inefficiency that the other four miss entirely. A team can have Elite DORA ratings — deploying 10 times per day with a 30-minute lead time and 1% failure rate — while running bloated, over-resourced CI pipelines that produce 5× more carbon per deploy than their industry peers. The four DORA metrics will show them as exemplary. CO₂/deployment will surface the waste.

How EmitCI calculates it

CO₂/deployment is a simple compound metric. EmitCI tracks every CI/CD workflow run with its full carbon cost (energy × grid intensity for every job, every step). For deployment events — workflow runs triggered by a merge to main or tagged as a deploy — it accumulates the total CO₂ for that deployment.

CO₂/deployment  =  Σ(energy × grid_intensity) for all jobs in the deploy workflow
                 +  upstream CI cost (test, lint, build)
                    allocated by the fraction of pipeline runs that result in a deploy

Deploy rate      =  deploys / total CI runs over the period
                    (low deploy rate → high upstream CI cost per deploy)

A team that runs 30 CI cycles per deploy (3% deploy rate) carries a very different carbon cost per successful deploy than a team with a 30% deploy rate, even if every individual run is identically sized. The metric naturally rewards trunk-based development and merge queues — the same practices the other DORA metrics reward.

What it looks like in practice

                DORA TIER      CO₂/DEPLOY     PATTERN
─────────────────────────────────────────────────────────────
Team A          Elite          1.2 gCO₂       Small, frequent, cached
Team B          Elite          18 gCO₂        Frequent but bloated runners
Team C          Medium         3.1 gCO₂       Less frequent but efficient
Team D          Low            420 gCO₂       Slow + uncached + oversized

  → Team B has Elite DORA but 15× Team A's carbon footprint
  → Team C has better carbon than Team B despite worse DORA
  → Team D is the only case where DORA and carbon align

Team B is the common case we see in fast-moving startups. Deployment frequency is high because the team ships constantly, but nobody has optimised the pipeline — there are no cache layers, the runner is over-specced, and the test suite runs in full even on a one-line config change. The DORA metrics praise the velocity. The CO₂/deployment metric flags the waste.

The SCI connection

The Green Software Foundation's Software Carbon Intensity (SCI) specification defines a functional unit — CO₂e per R, where R is something meaningful to the software system. For a deployment pipeline, R is a deployment. SCI/deployment is effectively a standardised version of CO₂/deployment, and it is the metric that CSRD auditors and ESG rating agencies are beginning to ask for.

EmitCI tracks SCI score over time alongside CO₂/deployment on the DORA page. Together they give you the trending view — is your pipeline getting more carbon-efficient as it scales? — and the absolute position — how does your SCI score compare to your industry percentile?

What to do when CO₂/deployment is high

HIGH CO₂/DEPLOYMENT — DIAGNOSIS TREE

Is deploy rate low? (< 10% of CI runs result in a deploy)
  → Yes: Fix the upstream cycle. Path filters, cancel-in-progress, branch pruning.
  → No: The deploy workflow itself is expensive.

Is the runner oversized?
  → Yes: Downsize. A 2-core runner is right for most test suites.

Is caching configured?
  → No: Add lockfile-keyed cache for package managers.

Is the test suite running on every PR commit?
  → Yes: Add cancel-in-progress concurrency controls.

Is the deploy happening from a high-carbon region?
  → Yes: Enable Green Scheduler to defer non-urgent deploys.

The recommendations EmitCI generates — cache npm, downsize runner, add path filters, shift to low-carbon window — each have a direct CO₂/deployment impact. The dollar saving and the carbon saving are the same improvement. The 5th DORA metric gives you the sustainability reporting angle on work your team was going to do anyway.