Data center waste heat recovery and reuse field guide

Waste heat reuse, and why the heat is becoming a product

Data center waste heat recovery is capturing the heat a facility would otherwise reject to the outdoors and putting it to use, instead of paying twice: once to make it and again to throw it away. Almost all the electrical power a data center draws ends up as heat. The servers turn watts into computation and waste heat in roughly equal measure, and the cooling plant exists to move that heat out of the hall. Recovery taps that stream before it leaves the fence.

For most of the industry's history the heat was simply a loss. You spent energy and water rejecting it to the air or to a cooling tower, and the only question was how cheaply you could get rid of it. The water side of that bill is its own subject, covered in the data center water use and WUE guide, and the cheapest way to reject heat at all, free cooling, has its own guide too.

What has changed is that the heat now has buyers. A district heating utility, a greenhouse, a leisure center, a process plant next door all need low-temperature heat, and a data center makes it continuously, year-round, at industrial scale. Sell it and a cost line becomes a revenue line. The catch is that the heat comes out at a low temperature, you usually need a heat pump to lift it, and there has to be someone nearby who will take it.

Why waste heat reuse is happening now

Three pressures arrived together. AI and GPU density pushed rack power from a few kilowatts to tens of kilowatts, and that density forced liquid cooling, which is the single change that makes recovered heat worth buying. Air-cooled halls reject heat at temperatures too low to do much with. Liquid cooling brings the heat out hot enough to use, so the technical barrier that held reuse back for years is falling on exactly the builds that are growing fastest.

The second pressure is sustainability and cost. Operators are under real scrutiny on energy and carbon, from regulators, from communities watching a grid fill up with data center load, and from their own corporate targets. Heat that displaces a neighbor's gas boiler is carbon the operator can point to, and energy that would have been rejected for nothing instead earns a payment.

The third is that heat has become a tradable product where the market exists for it. Stockholm's Open District Heating program pays operators per megawatt of heat delivered under standardized contracts, and the pitch is blunt: cost turns into revenue. That model only works where a district network and a willing utility already sit next to the building, which is the recurring theme of this whole subject.

The heat: how much there is and where it comes from

Nearly all the electricity a data center consumes leaves as heat, and the quantity is large. A facility drawing tens of megawatts of IT power is producing tens of megawatts of heat continuously, day and night, summer and winter. Meta's Odense data center in Denmark recovers on the order of 215,000 megawatt-hours of heat a year into the city's district network, roughly 45 MW of thermal output, enough to warm more than 12,000 homes by the operator's figures. That is one site.

The heat shows up in a few streams at different temperatures, and the temperature decides what you can do with each. Air returning from an air-cooled hall is warm but not hot, commonly in the range of 25 to 47 degrees C at the return. Water loops run warmer. Condenser or coolant loops can reach 40 to 50 degrees C, and direct-to-chip return water on a liquid-cooled build can come back higher still.

The single number that frames the whole problem is the output temperature of the stream you intend to recover. Everything downstream, whether you need a heat pump, what the heat is worth, and who will buy it, follows from how hot the heat is when it leaves the IT equipment.

The low-grade heat problem

The central difficulty is that data center waste heat is low-grade. There is a lot of it, but it comes out at a temperature far below what a boiler or a furnace produces, and most heat users are built around higher temperatures than a data center naturally delivers. Quantity is not the constraint. Quality is.

Low-grade here means the heat is useful but not hot. A traditional high-temperature district heating network may want supply water at 70 to 90 degrees C, while a data center stream might leave at 30 to 50 degrees C depending on the cooling design. That gap is the problem the rest of this guide keeps returning to. You either find a use that accepts low-temperature heat directly, or you spend energy to raise the temperature, and that energy is part of the deal whether you account for it or not.

This is why the newer, lower-temperature district heating networks matter so much to this subject. So-called fourth-generation networks are designed to run cooler, with supply temperatures that a liquid-cooled data center can sometimes meet with little or no upgrade. Where one of those networks exists, the low-grade problem shrinks. Where only a legacy high-temperature network exists, the lift, and its cost, grows.

Air cooling versus liquid cooling as the enabler

Liquid cooling is what makes the heat usable, and this is the most important single point in the subject. An air-cooled hall rejects heat into return air at a temperature so low that upgrading it to anything useful costs more energy than the heat is worth in most cases. The heat is real, but it is spread thin and cold. That is why decades of air-cooled data centers reused almost none of their heat.

Liquid cooling changes the temperature. Because water carries heat far more effectively than air and contacts the hot components directly, the heat comes out of a liquid-cooled system in a concentrated stream at a much higher temperature. A warm-water loop or a direct-to-chip system returns water in a range that a heat pump can lift cheaply, or that a low-temperature network can sometimes take as-is.

The mechanics of liquid cooling itself, the loops, the CDUs, the supply temperatures, sit alongside the free cooling story and belong with the cooling guides. For reuse, the one thing to hold onto is the direction of the trade: the same density push that is forcing AI builds onto liquid cooling is the push that finally makes their heat worth recovering. Air-cooled legacy halls are the hard case. Liquid-cooled builds are where reuse pencils out.

What liquid cooling makes possible

Direct-to-chip and immersion cooling produce warm-water loops, and the warmer the return, the more the heat is worth. Direct-to-chip systems move coolant to cold plates sitting on the processors, and measured return temperatures on these systems commonly land in the range of about 30 to 50 degrees C, with next-generation warm-water designs pushing supply temperatures toward 40 to 45 degrees C. Immersion cooling, where the equipment sits in dielectric fluid, similarly concentrates the heat into a liquid stream rather than spreading it through the room air.

The practical consequence is the temperature lift you have to buy. A stream returning at 45 to 60 degrees C needs only a modest lift, or sometimes none, to feed a low-temperature network. The same use fed from a 25 degree C air-return stream needs a large lift that eats much of the benefit. Higher return temperature is the lever, and it is set by the cooling design long before anyone thinks about a heat customer.

There is a tension worth naming. Pushing the IT loop hotter helps reuse, but it has to stay inside the temperature envelope the equipment tolerates. The reuse case never gets to override the thermal limits of the hardware, and the operating temperatures are a cooling-design decision first and a reuse decision second.

The heat pump that upgrades the temperature

Most reuse schemes need a heat pump to raise the recovered heat to a temperature the customer can use. A heat pump moves heat from the lower-temperature data center stream up to the higher temperature a district network or a building loop requires, and it spends electricity to do it. That electricity is the real cost of reuse that careless analyses leave out. You are not getting the heat for free. You are paying to upgrade it.

The efficiency is the coefficient of performance, the COP, which is the heat delivered divided by the electricity the heat pump consumes. The COP depends heavily on the lift. For a small lift, feeding a cold or low-temperature network from a warm liquid-cooled stream, COP figures in the range of about 3.5 to 6 are reported, meaning each unit of electricity moves several units of heat. For a large lift to a traditional 60 to 70 degree C network, COP commonly falls to roughly 2.5 to 3.5.

Run the balance honestly. The heat you sell has to be worth more than the electricity the heat pump burns plus its capital cost, and that margin is thin when the lift is large. The actual COP depends on the equipment, the source and sink temperatures, and the part-load profile, so the manufacturer's selection at your real conditions controls the number, not a rule of thumb.

The temperature math: source, sink, and lift

The whole design turns on two temperatures and the gap between them. The first is the temperature your data center delivers, set by the cooling type and the return conditions. The second is the supply temperature the use actually requires, set by the customer, whether that is a 40 degree C underfloor loop, a 55 degree C domestic hot water tank, or a 70 to 90 degree C legacy district main. The difference is the lift the heat pump has to provide.

Match a low-temperature use to a warm liquid-cooled source and the lift is small, the COP is high, and the economics can work without much upgrade. Force a low-grade air-return source up to a high-temperature legacy network and the lift is large, the COP is poor, and the electricity cost can swallow the value of the heat.

This is why the offtaker's required supply temperature is something to establish at the very start, not after the loop is designed. A use that takes lower-temperature heat is worth far more to you than a use that demands high-temperature heat, because the difference is paid for in heat-pump electricity every hour the system runs.

The uses and the offtakers for recovered heat

The list of things that want low-grade heat is longer than most operators expect, and the lower the temperature a use accepts, the easier the match. District heating is the largest and most common outlet where a network exists. Space heating for the data center's own offices and adjacent buildings is the simplest. Beyond those, the heat finds homes in places that run on warmth rather than high temperature.

Greenhouses and vertical farms use the heat to extend the growing season, and aquaculture is a natural fit because fish and shellfish want warm, stable water. Green Mountain in Norway warms a nearby lobster farm with its surplus heat, the cooled water sitting close to the temperature the lobsters prefer. Swimming pools and leisure centers are another clean match, with Deep Green in the UK heating local pools and a data center warming a training pool during the Paris 2024 Olympics. Industrial process heat, domestic hot water, and snow melt for sidewalks and ramps round out the list.

The pattern across all of them is the same. The best uses take low-temperature heat directly, sit close to the building, and want heat year-round or close to it. Those three traits decide whether a use is a real offtaker or just a nice idea.

The offtaker is the make-or-break

You need a heat buyer, nearby, with demand that runs most of the year, and without one there is no project. This is the part that kills more reuse schemes than any technical limit. The heat is real and the equipment exists, but if there is no customer within economic distance who wants the heat, the recovered energy has nowhere to go and the loop is a stranded asset.

Three things make an offtaker viable. Proximity, because heat does not travel far cheaply and the economics deteriorate quickly past a few kilometers of pipe. Demand profile, because a customer who only wants heat for three winter months leaves the system idle most of the year. And a contract, because the operator is committing capital to a loop and a heat pump and needs a buyer committed to taking and paying for the heat over years, not a handshake.

Settle the offtaker before the cooling plant is designed, not after. The customer's required supply temperature, demand profile, and willingness to sign drive the heat-pump selection, the loop design, and whether the project happens at all. An operator who builds the recovery hardware first and goes looking for a buyer second has the order backwards.

District heating and the city loop

District heating is the outlet that scales, and it is why the Nordics and parts of the EU lead this field. A district energy network distributes heat from central sources to many buildings through a loop of insulated pipe, and where that infrastructure already exists, a data center becomes one more heat source feeding it. The network handles distribution, demand aggregation, and the seasonal averaging across thousands of customers that a single building cannot provide.

The scale is what makes it work. Meta's Odense site feeds a city network and heats thousands of homes. Stockholm's Open District Heating connects multiple data centers into the city system under temperature-indexed contracts, with the utility investing in the pipe connection and the operator investing in the heat pump, and reported revenue on the order of a couple of million Swedish kronor per megawatt per year. That split, utility owns the network side, operator owns the upgrade side, is a common and workable partnership structure.

The hard dependency is the same one as always. District heating reuse needs a district network in place or planned within reach of the site. In regions without district energy, which includes most of North America, this outlet largely does not exist yet, and the smaller direct uses carry the load instead.

The heat exchanger and the interface

A heat exchanger sits between the data center's cooling loop and the reuse loop, and it earns its place by keeping the two systems separate. The most common type for this duty is a plate heat exchanger, a stack of thin plates that lets heat pass from one fluid to the other while the fluids never mix. Heat crosses. Water does not.

That isolation is the point. The data center's cooling fluid stays inside the data center's control, with its own water chemistry, its own filtration, and its own pressure regime, while the reuse loop or the heat pump runs on its own side. A leak or a fault on the customer's side cannot contaminate or depressurize the loop that is keeping the servers cool. The heat exchanger is the clean boundary that lets you sell heat without coupling the two systems together.

There is a small temperature penalty for the boundary. A heat exchanger needs a temperature difference across it to move heat, so the reuse side always comes out a few degrees below the data center side. On a low-grade stream where every degree matters, that approach temperature is part of the design, not a rounding error, and it gets accounted for in the lift the heat pump then has to provide.

The recovery loop, piping, and distribution

Past the heat exchanger sits the recovery loop: the piping, pumps, and controls that move the heat from the data center to wherever it is used. This is real infrastructure with real cost. Insulated pipe in the ground, pumping energy to push the water, and the distribution network out to the customer all have to be built and maintained, and on a district connection the pipe run can be the single largest capital item.

Distance is the enemy. Heat is lost along the pipe and pumping energy rises with the run, so the value of delivered heat falls the farther it has to travel. Reported economics deteriorate noticeably beyond roughly three to four kilometers, which is why proximity dominates the offtaker question. A perfect customer two kilometers away beats a perfect customer ten kilometers away by a wide margin, sometimes by enough to flip the project from viable to not.

The pumping energy belongs in the same honest accounting as the heat-pump electricity. It is parasitic load that does not show up in the headline heat figure but does show up in the operating cost, and on a long or undersized loop it can quietly erode the margin the project was sold on.

The seasonal demand mismatch

A data center makes heat every hour of every day. Heat demand does not work that way. Space heating and district loads peak in winter and fall away in summer, so the supply is flat and the demand is seasonal, and the two do not line up. This mismatch is one of the structural limits on how much heat actually gets reused, no matter how much is produced.

The consequence is that you still need full heat rejection capacity for the times the customer cannot take the heat. In summer, when demand drops, much of the heat goes back to the conventional cooling plant and gets dumped as it always was. The reuse system captures a fraction of the annual heat, not all of it, and the fraction depends on how well the demand profile matches the year-round supply.

Thermal storage can narrow the gap. Seasonal storage systems, aquifer thermal storage, pit storage, and similar, charge in summer and discharge in winter, and they let a network bank some of the surplus instead of wasting it. Storage adds cost and complexity, though, and how much it helps depends entirely on the site, the geology, and the network. The realistic planning assumption is partial capture, sized to the demand that genuinely exists, not the heat the building could in theory deliver.

What is the energy reuse factor (ERF)?

The energy reuse factor, ERF, is the share of a data center's energy that is reused outside the facility, expressed as a fraction or percentage, where higher is better. The Green Grid defined it to capture exactly the benefit that PUE cannot see: PUE measures efficiency inside the data center boundary, while reuse delivers its benefit outside that boundary, to a neighbor's heating system. ERF puts that exported energy back on the scoreboard.

ERF connects to PUE through a companion metric, energy reuse effectiveness, ERE. The relationship is ERE = (1 minus ERF) times PUE. When ERF is zero, no reuse, ERE equals PUE, exactly as you would want a well-behaved metric to behave. As reuse rises, ERE drops below PUE, crediting the facility for the energy it sends out to be used rather than rejected. The energy scorecard, PUE, and the water scorecard, WUE, both have their own guides on this site; ERF and ERE are the reuse counterparts.

Treat ERF as a real, reported number, not a marketing figure. It is calculated on metered energy, the same way PUE is, and where it is being reported to a regulator the calculation method is prescribed. The Green Grid framework and the applicable reporting rule control how it is figured.

The economics of recovering heat

The deal is capital and operating cost on one side against heat revenue and avoided cost on the other. On the cost side: the heat exchanger, the heat pump, the recovery loop and its pipe, and the parasitic electricity to run the pump and the heat pump. On the value side: the payment the offtaker makes for the heat, the cooling capital and energy the operator avoids by rejecting less heat conventionally, and sometimes incentives or grants tied to carbon reduction.

The payback swings hard on the lift and the distance. Reported figures put connections to low-temperature networks that need little or no heat pump in roughly the two-to-eight-year range, while connections to traditional high-temperature networks, with a large lift and the heat-pump cost that comes with it, stretch to something like eight to fourteen years. Those are illustrative ranges from published cases, not a quote for your site. The energy prices, the heat purchase rate, the lift, the distance, and who funds the pipe all move the number.

The strongest cases stack the value. Direct heat revenue plus avoided cooling capex and opex plus a carbon incentive together can carry a project that any one of them alone would not. Where heat is a tradable product, as in Stockholm, the per-megawatt payment can turn the cooling cost into a standing revenue stream, but that market does not exist in most regions yet.

The carbon and sustainability case

The carbon argument is what is driving much of this beyond the economics. Every unit of recovered heat that warms a building is a unit of heat the customer did not make by burning gas or oil, so the data center's waste displaces the offtaker's fossil fuel. That displaced combustion is the real emissions saving, and it lands on the heat customer's side of the ledger even though the data center created the opportunity.

The savings can be substantial at scale. The Tallaght district heating scheme in Ireland reported avoiding more than 1,100 tonnes of carbon dioxide in a year by using data center heat for local buildings, and city-scale connections like Odense displace far more by feeding networks that were previously burning fossil fuel.

Account for it honestly, though. The heat pump that upgrades the heat runs on electricity, so the net carbon benefit depends on how clean that electricity is and how dirty the fuel it displaces was. Displacing a gas boiler with heat upgraded by a heat pump running on a coal-heavy grid is a weaker case than the same swap on a clean grid. How the reuse is reported, and to whom the saving is credited, depends on the carbon accounting framework in play, so the reporting method controls what you can claim.

Designing reuse in versus retrofitting it

Reuse is far easier to build into a new facility than to bolt onto an old one, and the dividing line is the cooling type. A new build can be designed liquid-ready, with the recovery loop, the heat-exchanger space, the pump room, and the route to the customer planned from the start, and with operating temperatures chosen to suit a known offtaker. The marginal cost of designing it in is a fraction of the cost of adding it later.

Retrofitting a legacy air-cooled hall is the hard case, and it is hard for the reason that runs through this whole subject: the heat is too low-grade to be worth much. Even where you can physically tap the heat, upgrading a 25 to 35 degree C air-return stream to a useful temperature costs so much heat-pump electricity that the case often does not close. The honest answer for many older air-cooled facilities is that meaningful reuse waits for a cooling conversion to liquid.

The planning move on any new project is to assume reuse might be required or valuable within the asset's life, and to leave room for it: space, a route, and a cooling design that can deliver a usable temperature. Building liquid-ready costs little. Retrofitting from air-cooled costs a great deal.

Reuse cannot compromise cooling reliability

The data center's cooling has one job that overrides everything: keep the IT equipment within its thermal envelope. Heat reuse is a bonus loop hung off that primary mission, and it can never become a dependency. The plant has to be able to reject 100 percent of its heat conventionally, on its own, with the reuse system completely offline, because the day the heat customer's network trips, the servers still have to stay cool.

This is why the heat exchanger and the separate loops matter so much. The reuse side is isolated so that a fault, a leak, a shutdown, or a maintenance outage on the customer's side does nothing to the cooling that protects the hall. If the offtaker stops taking heat, the data center dumps it the old way and keeps running. Reuse improves the economics and the carbon footprint. It does not get a vote on whether the equipment stays cool.

Design and commission it accordingly. Full redundant heat rejection stays in place regardless of the reuse scheme, the controls fail the reuse loop safely back to conventional rejection, and nobody ever sizes the primary cooling on the assumption that the customer will always be there to take the heat. They will not always be there. Plan for the day they are not.

Regulation and policy pushing reuse

Policy is increasingly forcing the issue, most sharply in the EU. Under the EU Energy Efficiency Directive and Germany's Energy Efficiency Act, the EnEfG, new data centers face binding heat-reuse obligations. The German rule sets a minimum energy reuse factor for new facilities above a power threshold, reported as 10 percent for sites coming online from July 2026, rising in later years, with a reporting obligation already in force. The numbers, thresholds, and timelines are amended as the law develops, so the current text and any draft changes control, not last year's figure.

The direction of travel is clear even where the specifics are not. Regulators are moving from encouraging reuse to requiring it, and from voluntary reporting to mandatory reporting on platforms that make a site's waste heat potential visible to the market. An operator building in the EU now should assume reuse will be expected and design for it.

Outside the EU the picture is different and varies widely. Many jurisdictions have no reuse mandate and, just as importantly, no district network to reuse into. The policy and the infrastructure tend to arrive together, so the right move is to check what actually applies at your specific site and to the edition of the rule in force, because this area is changing fast and by region.

Commissioning the recovery system

Commissioning a reuse system has to prove two things at once: that the heat gets delivered to the customer at the agreed temperature and quantity, and that the cooling that protects the IT equipment is untouched by it. Both get tested, and the second is the one that cannot be assumed.

On the recovery side, verify the heat exchanger approach temperature, the heat-pump performance at real source and sink conditions, the loop flow and pumping, and the metering that the heat sale will be billed against. The COP a heat pump shows on a cool commissioning day at light load is not the COP it delivers at design lift under full load, so test across the conditions that matter, not just the easy one.

On the protection side, prove the failure modes. Drop the reuse loop and confirm the cooling plant picks up full heat rejection without disturbing the hall. Trip the customer connection and confirm the controls fall back cleanly to conventional rejection. The handoff to the offtaker, who owns what, who is alarmed on a fault, who is called at 2 a.m., is part of commissioning too, because a reuse loop with an unclear operational boundary is a reliability problem waiting to happen.

What to document and meter

Reuse is a commercial relationship and a reported metric, so the records have to support both. The heat delivered is metered because it is billed, the ERF is calculated and reported because it is increasingly a regulated number, and the offtaker's side is metered because the contract depends on it. A reuse scheme without clean metering is a dispute waiting to happen.

Capture the heat delivered over each period, the source and supply temperatures, the heat-pump electricity consumed and its COP, the parasitic pumping energy, the calculated ERF and the method behind it, and the offtaker meter readings that the billing reconciles against. Keep the commissioning results for the failure-mode tests on file, because the proof that reuse does not compromise cooling is something you will be asked for. A field operations tool like the FieldOS tools (tradeos) keeps the meter readings, the temperatures, the test records, and the handoff documentation in one place against the asset, instead of scattered across spreadsheets and email when the regulator or the offtaker asks.

Common mistakes

• Building the recovery hardware before securing a nearby offtaker with year-round demand.
• Trying to reuse very low-grade air-cooled heat, where the upgrade costs more energy than the heat is worth.
• Ignoring the electricity the heat pump burns to upgrade the temperature when figuring the economics.
• Letting the reuse loop become a dependency, so a customer outage threatens cooling reliability.
• Ignoring the seasonal demand mismatch and sizing on the heat produced rather than the heat the customer will take.
• Assuming a legacy air-cooled hall can easily reuse heat without a cooling conversion to liquid.
• Underestimating pipe distance, where economics deteriorate fast beyond a few kilometers.

Field checklist

Standards and references

The metrics come from the Green Grid, which defines the energy reuse factor (ERF) and energy reuse effectiveness (ERE) as the reuse companions to PUE, and these are the figures regulators and reporting frameworks reference. ASHRAE TC 9.9 governs the thermal guidelines for the IT equipment, which set the temperature envelope the cooling, and therefore the recovery stream temperature, has to respect.

On the energy side, the EU Energy Efficiency Directive and national implementations such as Germany's Energy Efficiency Act (EnEfG) are the policy instruments now imposing reuse obligations and ERF reporting on new data centers, with thresholds and timelines that are being amended as the law develops. District energy practice, including the design of low-temperature fourth-generation networks, sits with the district energy industry bodies and the network operator you connect to. Heat-pump performance, plate-heat-exchanger selection, and loop design follow standard mechanical engineering practice and the manufacturers' selection at your conditions.

Three things to hold onto across all of it, and they are the load-bearing conclusions of this guide. Liquid cooling is what makes the heat usable. You need both an offtaker nearby and, in most cases, a heat pump to upgrade the temperature. And the reuse system can never compromise the cooling reliability that protects the IT equipment. The specific temperatures, ERF figures, COP values, payback ranges, and policy numbers all depend on the design, the offtaker, the region, and the climate, so verify them against your project and the rule in force rather than carrying a number from a case study.

Units and terms

Waste heat reuse spans the data center, the mechanical, and the district energy worlds, so the same idea shows up under different terms across the documents.

Heat is measured in megawatts (MW) for capacity and megawatt-hours (MWh) for energy delivered, the same units as the electricity that produced it. Temperatures are in degrees C in most of this field, since the leading work is European. The energy reuse factor (ERF) is a percentage or fraction, and energy reuse effectiveness (ERE) is dimensionless like PUE. Heat-pump efficiency is the coefficient of performance (COP), heat out divided by electricity in.

Waste heat recovery

Capturing the heat a data center would reject and putting it to use instead of dumping it

Low-grade heat

Heat that is useful but at a low temperature, below what many uses want without upgrading

Energy reuse factor (ERF)

The share of a data center's energy reused outside the facility, higher is better; relates to PUE via ERE = (1 minus ERF) times PUE

Heat pump / COP

Equipment that raises the temperature of recovered heat using electricity; COP is heat delivered divided by electricity consumed

Offtaker

The heat buyer or user who takes the recovered heat, ideally nearby with year-round demand

District heating

A network distributing heat to many buildings through insulated pipe, the largest-scale outlet for recovered heat

Heat exchanger

The interface, often a plate type, that passes heat between the data center loop and the reuse loop without mixing the fluids

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is WUE?
• What is free cooling in a data center?
• What is a CDU in a data center?
• Why do data centers need liquid-cooling leak detection?
• What is direct-to-chip liquid cooling?