Green Software and Carbon Debt
Last updated . Sources are named and dated inline - how we source claims.
Inefficient software burns electricity that produces nothing. That has always been true. What changed is that somebody now has to put a number on it in a regulatory filing.
This guide covers where software energy actually goes, how carbon-aware scheduling works, why nearly every carbon figure attached to software is a model rather than a measurement, and how disclosure regimes are turning an optional virtue into a reported number.
Inefficiency is Carbon, Not Only Cost
Carbon debt is the accumulated energy waste nobody has ever been asked to account for: instances sized for a load test three years ago, an endpoint returning four hundred kilobytes of JSON so the client can use two fields, a job polling every second for an event that happens twice a day. Each is a small, boring inefficiency. Together they are a continuous electrical draw producing no user value.
In practice, carbon debt and cloud cost debt are mostly the same defect wearing different clothes. Compute you pay for and do not use is compute that draws power and does not use it either. That overlap is genuinely useful: most green software work can be justified twice with one piece of engineering.
But "mostly" is doing real work in that sentence, and pretending the two always align is how green initiatives lose credibility. They come apart in predictable places:
- Region choice. The cheapest region is not the cleanest. Only one of those trade-offs shows up on the invoice.
- Committed capacity. Prepaid discounts make idle resources cheap, removing the financial signal while the machine draws power exactly as before.
- Embodied emissions. Manufacturing carbon is spent before a machine is switched on, so replacing working hardware for marginal efficiency can be worse in total and still look better on the power bill.
- Time of day. A batch job at 3am may cost the same as one at noon while running on very different electricity.
Treat the overlap as a strong default and the divergences as cases needing a deliberate decision. That position survives contact with a sceptical finance team; a claim that every efficiency win is automatically a climate win does not.
Where Software Energy Actually Goes
Almost none of it goes where engineers instinctively look. Hot loops and algorithmic complexity are rarely the problem in a business system. The waste is structural, and it is usually in how the system waits, talks, and sits idle.
Idle Over-Provisioned Capacity
The largest category in most estates. A lightly loaded server does not draw a proportionally small amount of power; idle draw is substantial and continuous. Fleets sized for a peak that happens twice a year spend the rest of the year converting electricity into warm air. Consolidation, autoscaling, and scale-to-zero attack this directly.
Chatty Protocols
A screen making forty calls where four would do pays forty times the connection setup, round trips, and header overhead. Chatty service boundaries are usually an artifact of team structure rather than design, which is why they survive: no single team owns the aggregate.
Unbatched Work
Ten thousand single-row inserts cost far more than one batched write, and the same holds for index updates, message publishes, and remote calls. Per-item overhead is where the energy hides. Batching reliably improves throughput, cost, and emissions at once.
Uncompressed Payloads
Every byte is stored, replicated, backed up, transferred, and parsed at the other end. Missing compression, verbose serialisation, and endpoints returning whole objects when the caller needs three fields multiply that cost across every request, replica, and retention period.
Polling Instead of Events
A poll every five seconds against a resource that changes twice a day is seventeen thousand requests to learn nothing. Polling keeps clients awake, keeps radios active on mobile devices, and keeps back ends serving useless responses. Webhooks, queues, and subscriptions replace asking with being told.
Zombie Workloads
Nightly reports nobody opens, ETL feeding a decommissioned dashboard, log pipelines shipping terabytes to a bucket with no reader, test environments at full size all weekend. Zombie work is the purest carbon debt: all of the energy, none of the value.
The aggregate is now large enough to be tracked at national-policy level. The International Energy Agency estimates that "electricity consumption from data centres is estimated to amount to around 415 terawatt hours (TWh), or about 1.5% of global electricity consumption in 2024". Your service is a rounding error inside that. The industry is not.
Carbon-Aware Scheduling: Same Work, Cleaner Electricity
Most efficiency work reduces energy consumed. Carbon-aware scheduling does something complementary: it leaves consumption unchanged and moves the work to when or where the electricity is cleaner. Grid carbon intensity varies substantially through the day and between regions, so identical compute can carry very different emissions based on timing and location alone.
This is not theoretical. Google described a system that will "shift moveable compute tasks between different data centers, based on regional hourly carbon-free energy availability", aiming to move "as much energy consumption as possible to times and places where energy is cleaner". The Green Software Foundation states the same principle for its Carbon Aware SDK: "Carbon aware software does more when it can leverage greener energy sources, and less when the energy CO2 emissions are higher."
Time Shifting
Model training, batch reporting, backups, log compaction, index rebuilds, and CI on non-blocking branches are all deferrable by hours without anyone noticing. Give those jobs a deadline instead of a start time and let a scheduler pick the cleanest window inside it. The prerequisite is knowing which jobs are genuinely latency-insensitive, which most teams have never written down.
Location Shifting
Running the same workload where the grid is cleaner changes its emissions without changing a line of code. The constraints are real and often decisive: data residency law, latency to users, egress charges, and the fact that a cleaner region may be a more expensive one. This is an architecture decision, not a configuration flag.
Be sceptical of vendor claims about how much either technique saves. Published reduction percentages are usually derived from the vendor's model of a specific workload on a specific grid, and they do not transfer. The mechanism is sound; the headline number attached to it is not a measurement of your system.
Measuring Honestly: Modelled, Not Measured
This is where green software most often goes wrong, and it goes wrong in the direction of overconfidence. Nearly every carbon figure attached to software -- grams of CO2 per page view, per request, per gigabyte -- is the output of a model, not the reading of an instrument. There is rarely a meter anywhere between your code and the number. There is a chain of assumptions: a hardware profile, a utilisation-to-power curve, a facility overhead factor, a regional grid intensity for a given hour, a share of network and client-device energy, and manufacturing emissions amortised over an assumed device lifetime. Each assumption is defensible. Multiplied together they produce a range wide enough that two credible tools can disagree by an order of magnitude on the same page.
The best standard in this space is honest about exactly that. The Green Software Foundation's Software Carbon Intensity specification defines a score rather than a total: "SCI is a rate; carbon emissions per one unit of R", expanded as "SCI = (O + M) per R", where O is operational emissions and M is embodied emissions from hardware. The spec states plainly that "It is a score rather than a total; lower numbers are better than higher numbers, and reaching 0 is impossible."
Crucially, it does not pretend the inputs are all measured. Its own procedure asks you to "decide on the quantification method; real-world measurements, based on telemetry, or lab-based measurements, based on models" for each component inside the software boundary. A rate with a declared boundary and a declared method is a defensible engineering artifact. A single grams-of-carbon number with no stated boundary is marketing.
The specification is also standardised: the Green Software Foundation's own repository identifies the "Software Carbon Intensity (SCI) specification" as ISO/IEC 21031:2024. For a supplier questionnaire or a disclosure, that is the reference to reach for rather than a bespoke internal formula.
The uncertainty is acknowledged at the top of the field, not only at the bottom. IEA analysts note that "the operational and energy performance of data centres is relatively opaque, making demand estimates difficult". That is the IEA describing its own inputs.
Confident software energy numbers have also been wrong before, at scale. Masanet and colleagues, writing in Science, observed that "several oft-cited yet simplistic analyses claim that the energy used by the world's data centers has doubled over the past decade and that their energy use will triple or even quadruple within the next decade", and that such extrapolations "overlook strong countervailing energy efficiency trends that have occurred in parallel". The widely repeated figures were the confident ones, and they were the ones that needed recalibrating.
What This Means for Claims You Make
Report what you measured and label the rest. Energy drawn, instance hours, requests served, bytes transferred, and utilisation are observable. Emissions derived from them are an estimate, and the estimate should travel with its method, its boundary, and its emissions factors.
Prefer relative claims to absolute ones. "This change cut compute for the batch pipeline by 40 percent" is verifiable from your own telemetry. "This change saved 12 tonnes of CO2" depends on factors you did not measure and cannot defend under questioning. An unsourced carbon number is the same defect as an unsourced productivity number; it just has better public relations.
Front-End Energy Debt is Multiplied by Every Device
Server-side inefficiency is divided across users. Front-end inefficiency is multiplied by them. An oversized bundle is downloaded, parsed, compiled, and executed on every device that loads the page, most of them far slower and more power-constrained than the machine it was built on. A megabyte of unnecessary JavaScript shipped to ten million sessions is ten terabytes of transfer and ten million rounds of parsing that produced nothing.
The trend is not encouraging. HTTP Archive's Web Almanac records that "in July 2015, the median mobile home page was a meager 845 KB. As of July 2025, the same median page is now 2,362 KB". Nothing about the average web page became three times more useful in that decade.
Unused JavaScript
Whole libraries pulled in for one function, polyfills for browsers nobody runs, analytics tags that outlived the campaign. Parsing dead code costs battery on every load, and coverage tooling finds it in an afternoon.
Oversized Images
A full-resolution photograph scaled down in CSS transfers every byte and throws most of them away. Responsive sources, correct dimensions, and lazy loading below the fold remain widely ignored advice.
Third-Party Tags
Every tag is somebody else's code running on your users' devices and their power budget, usually with no internal owner and no review since it was added. Audit the list annually and delete what nobody can justify.
Perpetual Motion
Animations, carousels, and timers still running in background tabs stop the device idling. Pausing work when the page is hidden is a few lines of code and one of the highest-yield changes available.
The good news is that this is the same backlog as front-end performance work: already scoped, already tooled, already something your team knows how to do. See UX and design debt for the performance-budget machinery that keeps it from returning.
The Reporting Angle: From Voluntary to Disclosed
For twenty years, software sustainability was a values conversation. It is becoming a disclosure conversation, which is a different thing entirely, because a disclosure has an auditor, a deadline, and a signature at the bottom.
The European Union's Corporate Sustainability Reporting Directive is the clearest example. The European Commission describes it as requiring "companies above a certain size to disclose information on what they see as the risks and opportunities arising from social and environmental issues, and on the impact of their activities on people and the environment", reported "according to European Sustainability Reporting Standards (ESRS)". The first wave applied to the 2024 financial year, for reports published in 2025.
The scope is in flux, and it is better to say so than to quote a threshold that may not survive. The Commission's "stop-the-clock" measure "postpones the entry into application of the reporting requirements for those companies that were previously required to report for the first time for financial years 2025 or 2026", and the Omnibus simplification package "proposes to apply the CSRD only to the largest companies (those with more than 1000 employees)". The Commission records political agreement between the Parliament and the Council on that package in December 2025. Treat the direction of travel as settled and the exact perimeter as still moving.
Infrastructure-level reporting is already concrete. The recast Energy Efficiency Directive requires Member States to make owners and operators of data centres "with a power demand of the installed information technology (IT) of at least 500kW" publish specified information annually, and requires the Commission to "establish a European database on data centres". If you run your own facilities, that is a direct obligation. If you buy capacity, it is why your provider has started asking questions about your workloads.
It Arrives Through Procurement
Most engineering teams meet this as a questionnaire from a customer in scope, long before it applies to them directly. Reporting obligations propagate down the supply chain as contract terms, exactly as security questionnaires did.
Lineage Beats Estimates
An auditable number needs a traceable source. Start collecting the primitives now -- instance hours by region, provider energy data, transfer volumes -- because reconstructing a defensible history later is expensive and often impossible.
Overstating is the Real Risk
Once a figure is in a filing it carries legal weight, so the cautious, boundary-declared, clearly-modelled estimate is the safe one. See global regulation debt for how these regimes interact.
Why Green Work is Usually Just Efficiency Work
Here is the practical argument, and it is why this page sits on a technical debt site rather than a sustainability one. Nearly every item on a green software backlog is already on some other backlog. Right-sizing instances is FinOps. Removing zombie jobs is operational hygiene. Batching writes is a database optimisation. Replacing polling with events is an architecture improvement. Shrinking bundles is front-end performance.
Framing that as a weakness is a mistake. It is the most useful property green software work has, because the work needs no budget line, no headcount, and no executive sponsor of its own. It needs a second justification attached to work that already had a first one, and a second justification is often what moves an item from "eventually" to "next quarter".
So do not build a separate carbon programme. Add a carbon column to the backlog you already have. Put energy and utilisation metrics beside the cost metrics in the dashboard your platform and DevOps team already runs. Add an efficiency section to the architecture review template. When the sustainability report needs numbers, the engineering will already have been done for reasons finance agreed with.
Where They Agree
Idle capacity, zombie workloads, oversized payloads, chatty calls, unbatched writes. Every one is cheaper and cleaner to fix. Start here and you never have to win an argument about motives.
Where They Diverge
Region selection, hardware replacement cycles, committed-capacity pricing. These need an explicit decision with both numbers on the table, because optimising one can make the other worse.
Why Pressure Grows
The IEA's base case projects data centre electricity consumption doubling "to reach around 945 TWh by 2030 ... representing just under 3% of total global electricity consumption". Scrutiny follows load, and that is a scenario rather than a forecast.
Related Resources
Cloud Cost Debt
The financial twin of this page: over-provisioning, orphaned resources, and the FinOps practices that find them.
Global Regulation Debt
How overlapping international regimes turn into engineering work, and how to build for disclosure once rather than repeatedly.
UX & Design Debt
Front-end performance budgets, bundle discipline, and the tooling that keeps page weight from creeping back up.
DevOps & Infra Debt
Autoscaling, environment lifecycle, and the platform automation that makes scale-to-zero the default instead of a project.
Frequently Asked Questions
Most of the time yes, and that is a feature rather than an embarrassment. Idle capacity, zombie workloads, oversized payloads, chatty service calls, and unbatched writes all cost money and burn electricity, so one piece of engineering satisfies two justifications. The overlap breaks down in specific places worth knowing: the cheapest region is not always the cleanest, committed capacity removes the cost signal while power draw continues, and replacing working hardware for marginal efficiency can raise total emissions because manufacturing carbon is already spent.
You can measure energy-adjacent quantities directly and estimate emissions from them, and it matters enormously which one you claim to be doing. Instance hours, utilisation, bytes transferred, requests served, and sometimes actual power draw are observable. Converting those into carbon requires assumed hardware profiles, power curves, facility overheads, regional grid intensity factors, and amortised manufacturing emissions. Publish the measured quantities, publish the estimate with its boundary and method attached, and prefer relative claims over absolute tonnage you cannot defend.
The SCI is the Green Software Foundation's specification for expressing the carbon intensity of a software system. It defines a rate rather than a total: carbon emissions per functional unit, written as SCI = (O + M) per R, where O is operational emissions, M is embodied emissions from the hardware involved, and R is the unit you scale by, such as a user, a request, or a job. The specification states it is a score rather than a total, that lower is better, and that reaching zero is impossible. The Green Software Foundation identifies it as ISO/IEC 21031:2024.
Possibly not directly, and probably indirectly. The Corporate Sustainability Reporting Directive obliges companies above a size threshold to report against the European Sustainability Reporting Standards, with the first wave reporting on the 2024 financial year. The perimeter is being redrawn: a stop-the-clock measure postponed application for later waves, and the Omnibus simplification package proposes limiting the directive to the largest companies, with political agreement reached in December 2025 and the final threshold not yet settled. Expect the obligation to reach you as a customer questionnaire regardless.
Start with waste that has no defenders. Find workloads producing output nobody consumes: nightly reports with no readers, ETL feeding a decommissioned dashboard, log pipelines writing to a bucket nobody queries, and non-production environments running at full size overnight and at weekends. Then look at utilisation across the fleet and right-size the worst offenders. Then replace the noisiest polling loops with events. None of that needs a carbon model, a new budget, or an executive mandate, and all of it cuts cost and energy together.
The usual cause is not dishonesty but a modelled number that lost its caveats somewhere between the engineer and the slide. Three habits prevent it. Never publish a carbon figure without its boundary, its method, and its emissions factors travelling alongside it. Keep the language proportionate to the evidence, because words like estimated and modelled are accurate and cost you nothing. And do not quote a vendor's headline savings percentage as though it applied to your system, because it came from their workload on their grid.
Find the Work That Pays Twice
Pick one workload this quarter that produces output nobody reads, and delete it. It is the cheapest thing on your backlog, it cuts cost and energy at once, and nobody will argue with you about it.