PUE Explained: ISO/IEC 30134-2 and What the Number Hides

Power usage effectiveness (PUE) is a data center's total annual energy divided by the annual energy delivered to its IT equipment. A PUE of 1.5 means every kilowatt hour of computing costs another half a kilowatt hour of cooling, power conversion and lighting. The Green Grid defined it; ISO/IEC 30134-2 now standardises it, and its second edition was published on 16 January 2026.

PUE is the most quoted number in data center engineering and one of the most misread. It tells you how much energy the building spends supporting the IT load, not whether the servers do useful work, how much water or carbon sits behind each kilowatt hour, or whether the waste heat warms anything. This post goes one level deeper than our explainers on data center water use, climate siting and air versus liquid cooling. It covers the formula, the standard, measurement points, two worked examples, companion metrics, EU reporting rules and a metering method for a homelab or small server room.

Key takeaways

• PUE = total facility energy ÷ IT equipment energy, both measured in kWh over a full year. The lowest possible value is 1.0. Its reciprocal, DCiE, expresses the same thing as a percentage.
• The Green Grid, an industry consortium, originally defined PUE and later passed its standardisation to ISO and IEC. ISO/IEC 30134-2 was first published on 19 April 2016, amended in 2018, and replaced by a second edition (ISO/IEC 30134-2:2026) on 16 January 2026.
• Where you measure IT energy changes the answer. European rules require IT energy measured at the output of every UPS feeding IT equipment (category 1 in EN 50600-4-2), or at the PDU output where there is no UPS (category 2).
• PUE can get worse when you save energy, because consolidation or fan removal shrinks the denominator faster than fixed overhead.
• PUE ignores IT efficiency, utilisation, water, carbon, renewable supply and heat reuse. ISO/IEC 30134 has separate parts for REF, ITEEsv, ITEUsv, ERF, CER, CUE and WUE.
• In the EU, every data center with 500 kW or more of installed IT power must report annually to a European database. The Commission, not the operator, calculates PUE, WUE, ERF and REF from the reported data. On 21 September 2026 the Commission proposed a common rating scheme and opened a consultation on minimum performance standards that runs until 14 December 2026.

What is PUE?

PUE compares two quantities of energy:

PUE  = total facility energy (kWh) / IT equipment energy (kWh)
DCiE = IT equipment energy / total facility energy x 100%  = 100% / PUE

The US Department of Energy's Federal Energy Management Program (FEMP) defines PUE in its Best Practices Guide for Energy-Efficient Data Center Design (revised July 2024) as "the ratio of the total annual energy to run the data center facility to the total annual energy drawn by all IT equipment." The same guide notes that PUE is "mathematically bounded from 1.0 to infinity." A value of exactly 1.0 would mean every kilowatt hour entering the facility reaches IT equipment and nothing is spent on cooling, conversion losses or lighting. No real facility gets there, because transformers, UPS systems and fans all dissipate energy.

DCiE (data center infrastructure efficiency) is the reciprocal of PUE as a percentage: a PUE of 1.25 is a DCiE of 80 percent. Oak Ridge National Laboratory's metering protocol for FEMP (September 2010) defined both and credited The Green Grid's white papers.

What counts as IT equipment and what counts as facility

The ORNL protocol is a useful, plain language split, and it matches how the standards draw the line:

Anything inside the server chassis, including its fans and power supply losses, counts as IT. Anything outside, including the pumps of a coolant distribution unit (CDU) feeding liquid cooled racks, counts as facility. Worked example 2 shows why that boundary matters.

Energy, not power

PUE is defined over energy (kWh), not instantaneous power (kW). FEMP explains that a year of energy captures free cooling hours and changing IT load; a single reading on a cool morning flatters almost any facility. Always ask "over what period, and measured where?"

Who introduced PUE, and how did it become ISO/IEC 30134-2?

PUE came from The Green Grid, an industry consortium whose website copyright line starts in 2007; we could not retrieve its original white paper to confirm the exact first publication date. FEMP's guide states that "PUE was originally defined by The Green Grid," and that the organisation passed development and standardisation of the metric to ISO and IEC. The Green Grid's own consolidated reference, "PUE: A Comprehensive Examination of the Metric", is dated 4 February 2014 on its library page. That page says the book "supersedes all prior white papers" on PUE, covers dedicated, mixed use and specialised facilities, and discusses partial PUE and waste heat reuse. It is free to members and sold to everyone else through ASHRAE's bookstore, which is why few people outside the industry have read it.

The international standard sits in the ISO/IEC 30134 series, "Information technology, Data centres, Key performance indicators", owned by the joint committee ISO/IEC JTC 1/SC 39. ISO's own open data catalogue shows the history:

A note on sourcing. iso.org blocks scripted clients, so we could not fetch the standard's catalogue page directly. The dates, page counts, committee and scope text above come from ISO's public open data feed of deliverables metadata, which ISO publishes for exactly this kind of reuse. We have not read the paid text of the standard, and we say so where a detail depends on it.

What the 2026 edition covers

According to ISO's published scope, the 2026 edition defines PUE, introduces measurement categories, relates the KPI to infrastructure, IT equipment and IT operations, defines measurement, calculation and reporting, and explains interpretation. The 2016 scope said almost the same, except that PUE derivatives such as partial PUE moved from Annex D to Clause 9. If your internal procedures or contracts cite "ISO/IEC 30134-2:2016", they now cite a withdrawn document, and it is worth updating the reference when you next revise them.

Where must energy be measured?

PUE has two measurement points that matter: one for the numerator and one for the denominator.

The numerator (total facility energy) is measured where energy enters the data center: the utility meter for a dedicated building, or a sub meter on the feed that serves only the data center in a mixed use building. ORNL's protocol defines total facility power as "the power measured at the utility meter", dedicated solely to the data center. The EU regulation adds that total energy "includes the use of electricity, fuels and other energy sources used for cooling", and that energy from back up generators must be measured separately. If chilled water comes from a central plant shared with offices, you have to meter or estimate the data center's share of that plant.

The denominator (IT equipment energy) can be measured at several points along the electrical path, and each one gives a slightly different PUE. The further downstream you measure, the more conversion losses you correctly move into the facility side.

The EU Delegated Regulation 2024/1364 is explicit. Data centres "shall measure the combined annual energy consumption at every uninterruptible power system (UPS) connected to data centre information technology equipment", following the category 1 methodology for PUE in CEN/CENELEC EN 50600-4-2. Where there is no UPS, for example in direct current data centres, IT energy may be measured at the PDU (category 2) or at a measurement point the data centre specifies.

ISO's scope confirms that ISO/IEC 30134-2 "introduces PUE measurement categories", and the EU text confirms the first two categories map to UPS output and PDU output. We could not read the paid text to confirm how the 2026 edition defines its highest category or whether it changed the category definitions from 2016, so check the standard itself before you write a category number into a contract. What does not change is the principle: a PUE without its measurement point is not comparable with any other PUE.

The same logic applies to time: the EU regulation and FEMP both use annual energy. Monthly or daily PUE is useful for internal tracking, as long as it is labelled as such.

Worked example 1: PUE and DCiE for a small server room

Take a 40 square metre server room in an office building. It has its own electrical sub panel with a revenue grade sub meter, one 30 kVA UPS feeding all racks, two computer room air conditioners (CRACs) and LED lighting. The building's monthly report gives you two numbers per month: the sub panel meter (total room energy, including the UPS input, the CRACs and the lights) and the UPS output energy (IT energy, category 1).

May. The sub meter reads 9,360 kWh for the month. The UPS output reads 6,120 kWh.

PUE  = 9,360 / 6,120 = 1.529  (round to 1.53)
DCiE = 6,120 / 9,360 = 65.4%
Overhead = 9,360 - 6,120 = 3,240 kWh

Every 100 kWh delivered to servers costs another 53 kWh of facility energy. To find where the 3,240 kWh went, you need a few more readings. Suppose you clamp a temporary logger on each CRAC feed and read the UPS input and output counters:

At 0.15 US dollars per kWh, the overhead costs 486 dollars in May. Cooling is the first target. A UPS loss of 8.1 percent of output (540 ÷ 6,120) suggests the UPS runs at a low fraction of its rating, which is the second target.

The whole year. Here are twelve months for the same room:

Three lessons sit in this table.

1. The annual PUE is the ratio of the annual sums, 106,800 ÷ 72,170 = 1.480, not the average of twelve monthly PUEs. Here the simple average happens to be 1.476, close to the true figure, but the two diverge whenever IT load changes a lot across the year. Always sum energy first, then divide.
2. The best month is 1.37 and the worst is 1.61. Quoting December's 1.37 as "our PUE" overstates efficiency by about 0.11, and that is exactly the kind of number that ends up on a slide.
3. Summer overhead is nearly double winter overhead (3,980 kWh against 2,080 kWh) while IT load rises only 18 percent. The room has no economiser, so the CRACs run their compressors all year. That points to the fix: an air side or water side economiser, or simply raising the supply air setpoint within the inlet range the hardware vendor supports.

What if you measured at the PDU instead? Suppose the racks' metered PDUs report 70,050 kWh for the year, because 2,120 kWh is lost in the cords, the in-room transformer and the PDUs themselves. The PUE becomes 106,800 ÷ 70,050 = 1.525. Same room, same year, a different PUE, purely because the denominator moved downstream. Neither number is wrong. They answer slightly different questions, which is why the measurement category belongs next to every PUE you publish.

Worked example 2: air to direct to chip liquid cooling, and why PUE can rise when IT load drops

Part A: moving to direct to chip cooling

Consider a 1 MW (average IT load) air cooled hall. Average power over the year:

Annual facility energy is 1,500 kW × 8,760 hours = 13.14 GWh.

Now the operator retrofits the compute racks with direct to chip (DLC) cold plates fed by a coolant distribution unit. Warm water from the cold plates goes to dry coolers that run without chillers for most of the year. Because the cold plates remove most of the processor heat, server fan power falls from 80 kW to 25 kW for the same workload. Residual air cooling still handles memory, drives and power supplies.

DLC PUE = 1,210 / 945 = 1.280
Facility energy saved = (1,500 - 1,210) x 8,760 = 2,540,400 kWh per year (19.3%)

Two effects are tangled here. The real one: cooling drops from 380 kW to 150 kW because warm water needs far less compressor work. The accounting one: 55 kW of fan power left the denominator. Had the fans stayed at 80 kW with the same cooling saving, PUE would be 1,265 ÷ 1,000 = 1.265, better than 1.280, despite higher total energy. A genuine saving inside the server makes PUE look worse.

Now watch what happens if the CDU is an in-rack unit powered from the rack PDUs rather than a floor standing unit on a facility panel. Its 15 kW of pump power moves from the numerator to the denominator:

In-rack CDU: PUE = 1,210 / (945 + 15) = 1.260

Same hardware, same bill, and PUE improved by 0.02 by moving a pump to a different power strip. When you compare PUE across a retrofit, record where every new pump, fan and controller draws power.

Part B: why PUE can rise when IT load drops

Most facility overhead has a fixed part (UPS no load losses, minimum chiller and air handler operation, lighting, controls) and a part that scales with IT load. Model a hall where the overhead is 400 kW fixed plus 0.25 kW per kW of IT load:

The team cut total facility power by 625 kW (38 percent, roughly 5.5 GWh a year), yet PUE went from 1.65 to 2.05. A PUE only dashboard would call this a failure.

The answer is to follow consolidation with right sizing: retire a UPS module, raise chilled water temperature, slow air handlers and contain the remaining racks. Each shrinks the fixed 400 kW, and only then does PUE recover. This is also why FEMP's guide puts IT efficiency first, noting that measures in IT have "a cascading effect of secondary energy savings" on mechanical and electrical systems. The correct headline metric for the consolidation project is total kWh, not PUE.

What does PUE not capture?

PUE measures one thing well: infrastructure overhead relative to IT energy. FEMP's guide warns that PUE "does not define the overall efficiency of an entire data center, but only the efficiency of the supporting equipment." Here is what sits outside it.

IT efficiency. Idle, ten year old servers at PUE 1.2 can use far more energy per unit of work than a busy modern cluster at PUE 1.5. ISO/IEC 30134-4 (ITEEsv) and 30134-5 (ITEUsv) address this, and the EU regulation asks operators to report a server compute capacity figure, C_SERV, built from standardised CPU performance values.

Utilisation and redundancy. A 2N facility running each power path at half load or less has higher overhead than a single path facility at 90 percent load. The Commission's FAQ on the European database makes the same point, saying a lower utilisation rate is often "a deliberate design feature rather than a result of underperformance."

Water. Evaporative cooling can push PUE down while consuming large volumes of water. Water usage effectiveness (WUE) measures this; see our water use explainer for direct and indirect water.

Carbon and renewables. Identical facilities on a coal heavy grid and on hydro power have the same PUE and very different emissions. Carbon usage effectiveness (CUE) captures this, and the renewable energy factor (REF) records the renewable share of total energy.

Heat reuse. A facility that sends its waste heat to a district heating network has the same PUE as one that dumps it into the sky. The energy reuse factor (ERF) captures this. The older Green Grid metric ERE (energy reuse effectiveness), described in FEMP's guide, subtracts reused energy from the numerator and so can fall below 1.0, which is one reason PUE itself is kept strictly at 1.0 or above.

Source energy. PUE uses site energy. FEMP notes that ENERGY STAR defines a "Source PUE" on source energy, which matters when a site burns fuel as well as buying electricity.

Climate. A facility in a cold, dry climate can economise most of the year; one in a hot, humid climate cannot. The EU regulation asks operators to report cooling degree days computed with a base temperature of 21 degrees Celsius, so that PUE can be read against climate. Our climate siting post covers this in depth.

The ISO/IEC 30134 family

ISO's catalogue and FEMP's 2024 guide list the series as follows. Dates are publication dates from ISO's open data.

ISO's open data also shows revisions in progress for WUE (a committee draft), ERF and the general requirements. ISO's scope text says ERF does not reflect the efficiency of the reuse process itself, which sits outside the data center.

Comparison table: PUE, WUE, CUE, ERF, REF and server utilisation

The pattern is the same for every row: a ratio is only as honest as its boundary and its period. Every metric in the table can be improved on paper by moving the boundary.

What do regulators now ask for?

European Union: Energy Efficiency Directive (EU) 2023/1791, Article 12

The recast Energy Efficiency Directive, signed in Strasbourg on 13 September 2023, made data center reporting law. Article 12 says that "by 15 May 2024 and every year thereafter", Member States must require owners and operators of data centres with an installed IT power demand of at least 500 kW to make the information in Annex VII publicly available, except where trade secrets or confidentiality law protects it. It also:

• exempts data centres used exclusively for defence and civil protection;
• requires the Commission to set up a European database on data centres, public at an aggregated level;
• asks Member States to encourage owners and operators of data centres of 1 MW or more to take into account the best practices in the most recent European Code of Conduct on Data Centre Energy Efficiency;
• required a Commission assessment by 15 May 2025, with proposals such as minimum performance standards where appropriate.

Delegated Regulation (EU) 2024/1364: the first phase of the rating scheme

The Commission adopted Delegated Regulation 2024/1364 on 14 March 2024, and it appeared in the Official Journal on 17 May 2024. It sets the information and KPIs to be reported and the measurement methods. Key points from the text:

• Deadlines. Article 3: "By 15 September 2024, then by 15 May 2025, and every year thereafter", reporting operators communicate the Annex I and Annex II information to the European database.
• The Commission calculates the indicators. Annex III defines four data centre sustainability indicators: PUE = E_DC ÷ E_IT, WUE = W_IN ÷ E_IT (with E_IT in MWh), ERF = E_REUSE ÷ E_DC and REF = E_RES-TOT ÷ E_DC. The Commission's FAQ confirms that PUE, WUE and ERF are "calculated by the Commission, not directly reported by the operators."
• Measurement methods. Total energy E_DC follows CEN/CENELEC EN 50600-4-2 "or equivalent" and includes electricity, fuels and other energy used for cooling; back up generator energy is reported separately. IT energy E_IT is measured at the output of every UPS connected to IT equipment (category 1), or at the PDU (category 2) where there is no UPS. Waste heat reused follows EN 50600-4-6, renewable energy follows EN 50600-4-3, and water follows EN 50600-4-9.
• Size categories for publication. Annex IV publishes aggregated data by size: very small (100 to 500 kW), small (500 to 1,000 kW), medium (1 to 2 MW), large (2 to 10 MW) and very large (more than 10 MW). Averages are weighted by total energy consumption, and a category is published per type and size only if it holds data from at least three data centres.
• Climate context. Operators report cooling degree days with a base temperature of 21 degrees Celsius.

The Commission's FAQ (version 1.9, September 2026) adds that the 500 kW threshold applies per site to installed IT capacity, not design capacity. Installed IT power is the nameplate power of the IT equipment; reporting UPS rated capacity instead "often results in an overestimation." Where cooling is shared with offices and not separately metered, operators must estimate the data center's share, and where alternative energy sources are used, "all forms of energy consumption should be included."

What changed in 2026

The Commission's data centre page, checked on 25 October 2026, reports that its assessment of the 2024 reporting period was published in July 2025, with the 2025 report in preparation. On 21 September 2026 it proposed a common rating scheme to make energy and water use more transparent and comparable, after a call for feedback from 26 March to 23 April 2026. The same day it opened a consultation on minimum performance standards, running until 14 December 2026, with a legislative proposal planned for the second quarter of 2027. PUE is moving from a marketing number to a regulated, Commission calculated figure that may one day carry a minimum.

United States

The United States has no equivalent federal reporting mandate for private data centers. FEMP's 2024 guide gives PUE benchmarks of 1.6 ("standard"), 1.4 ("good") and 1.1 ("better"). The Department of Energy also announced in December 2024 a Lawrence Berkeley National Laboratory report estimating that US data centers used about 176 TWh in 2023, roughly 4.4 percent of US electricity, and could use 325 to 580 TWh by 2028, between 6.7 and 12 percent.

For global context, the European Commission cites the International Energy Agency's estimate that data centres use about 415 TWh a year, roughly 1.5 percent of world electricity, and could reach about 945 TWh by 2030.

Step by step: measure PUE in a homelab or small server room

You need one meter on the room's supply, IT readings from the equipment and a short script. The method works for a two rack closet or a small enterprise room.

Step 1: draw the boundary

Write down what is inside your "data center": the racks, the UPS, the cooling, the room lighting and any network cabinet that serves only the racks. Everything else on the same circuit is outside. If the air conditioner also cools an office, estimate a share, as the EU FAQ asks larger operators to do.

Step 2: meter the total

Option A, a sub meter: have a licensed electrician fit a DIN rail energy meter or a current transformer (CT) monitor on the room's circuit. Read kWh, not watts.

Option B, plug in meters: for a homelab that runs from wall outlets, a plug in energy meter on each outlet feeding the rack, the UPS and the cooling unit gives you the total by addition.

Safety first: do not open a distribution panel or install CTs yourself unless you are qualified.

Step 3: measure IT energy

Pick one measurement point and stick with it. For most small rooms the UPS output counter is the easiest (category 1). If you want more detail, read the IT equipment directly.

Server management controllers (IPMI and DCMI). Many servers expose power readings through their baseboard management controller (BMC). The ipmitool manual lists a dcmi command for the Data Center Management Interface; on BMCs that support DCMI power management, you can read the current power from the local host:

# Read the current power draw reported by this server's BMC (run as root on the host)
sudo ipmitool dcmi power reading

# List all sensors with readings; look for power and current sensors
sudo ipmitool sensor list | grep -i -E "watt|pwr|power"

Redfish. Newer BMCs support DMTF's Redfish API. The Redfish EnvironmentMetrics schema defines PowerWatts ("the total power, in watt units, for this resource") and EnergykWh ("the total energy, in kilowatt-hours, for this resource"). Paths vary by vendor, so discover them from the service root first:

# Discover chassis resources, then read environment metrics for one chassis
BMC=https://bmc.mgmt.example.internal
curl -s --cacert bmc-ca.pem -u monitor:"$BMC_PASS" "$BMC/redfish/v1/Chassis" | jq '.Members'
curl -s --cacert bmc-ca.pem -u monitor:"$BMC_PASS" \
  "$BMC/redfish/v1/Chassis/1/EnvironmentMetrics" | jq '{PowerWatts, EnergykWh}'

Use a read only BMC account, verify the BMC's certificate rather than turning verification off, and keep the BMC on a separate management network. BMCs are powerful remote management interfaces and should never be reachable from the internet.

Metered or switched PDUs. Rack PDUs with outlet or inlet metering report energy over SNMP or their own web API. Poll the energy counter (kWh) rather than instantaneous power where you can, because counters capture every second between polls. Use SNMPv3 with authentication and privacy where the PDU supports it.

Linux RAPL counters, with a caveat. The Linux powercap framework exposes energy counters such as /sys/class/powercap/intel-rapl:0/energy_uj for the processor package. They cover the CPU package, not the whole server at the wall, so never use them as the PUE denominator.

# CPU package energy over 60 seconds, in joules (package domain only, not wall power)
a=$(cat /sys/class/powercap/intel-rapl:0/energy_uj); sleep 60
b=$(cat /sys/class/powercap/intel-rapl:0/energy_uj)
echo "package energy: $(( (b - a) / 1000000 )) J"

The counter wraps at max_energy_range_uj, so a script that runs for long periods needs to handle the wrap.

Step 4: log both at the same interval

Record total kWh and IT kWh at the same timestamps, every 15 minutes or every hour, into a CSV with three columns: timestamp,total_kwh,it_kwh, where each value is the energy used in that interval. If your meters report cumulative counters, store the counter and compute the difference.

Step 5: compute PUE per month from energy sums

#!/usr/bin/env python3
"""Monthly and annual PUE from interval energy readings (kWh)."""
import csv
from collections import defaultdict

totals = defaultdict(lambda: [0.0, 0.0])  # month -> [total_kwh, it_kwh]
with open("energy.csv", newline="") as f:
    for row in csv.DictReader(f):
        month = row["timestamp"][:7]          # YYYY-MM
        totals[month][0] += float(row["total_kwh"])
        totals[month][1] += float(row["it_kwh"])

year_total = year_it = 0.0
for month in sorted(totals):
    total, it = totals[month]
    year_total += total
    year_it += it
    print(f"{month}  total={total:9.1f}  it={it:9.1f}  PUE={total / it:5.2f}  DCiE={100 * it / total:5.1f}%")

print(f"ANNUAL  PUE={year_total / year_it:5.2f}  (sum of energy, not mean of monthly ratios)")

Label the output with the measurement point: "PUE, category 1 (UPS output), 12 months ending September 2026."

Step 6: find the biggest overhead

Subtract IT energy from total energy, then split the remainder with a few targeted readings:

In a homelab the surprise is often a lightly loaded UPS or a portable air conditioner in a closed closet; in small enterprise rooms it is usually cooling at a low setpoint with no containment.

Step 7: review monthly, compare annually

Track monthly PUE as a trend and total kWh as the headline. Compare this year's annual PUE against last year's at the same measurement point. If you change the measurement point, restate the previous year at the new point or say clearly that the series has a break.

Common mistakes

1. Quoting the best month as the annual PUE. In worked example 1 the best month was 1.37 and the year was 1.48. Always publish the 12 month figure and say which months it covers.
2. Measuring at the wrong boundary. Using UPS input instead of UPS output puts UPS losses in the denominator and flatters PUE. Using IT nameplate ratings instead of measured energy is not PUE at all.
3. Comparing PUE across climates without context. A 1.4 in a hot, humid region can represent better engineering than a 1.2 in a cold one. Report cooling degree days alongside PUE, as the EU regulation does.
4. Averaging monthly ratios. The annual PUE is the ratio of annual sums. Averaging monthly PUEs gives low load months the same weight as high load months.
5. Moving loads across the line. In-rack CDUs, rear door coolers and rack mounted fans powered from IT PDUs drop into the denominator. Document where every cooling component draws its power.
6. Leaving out non electric energy. Generator fuel, gas fired absorption chillers and purchased chilled water are part of total facility energy. The EU regulation says so explicitly.
7. Presenting partial PUE as site PUE. A partial PUE for one hall or one cooling system excludes shared plant. It is a useful derivative, but it is not the facility PUE.
8. Judging an IT efficiency project by PUE. Consolidation, power capping and fan removal save energy and can raise PUE. Judge them on total kWh and work done.
9. Citing a withdrawn edition. ISO/IEC 30134-2:2016 and its 2018 amendment were replaced on 16 January 2026. Update references in procedures, contracts and audit evidence.

FAQ

What is a good PUE for a data center?

FEMP's 2024 guide uses 1.6 as "standard", 1.4 as "good" and 1.1 as "better", and says the average data center is around 1.6. Whether a value is good depends on climate, redundancy level, size and measurement point, so compare against facilities of similar size and climate measured at the same point.

How do you calculate PUE?

Divide total facility energy by IT equipment energy for the same period, both in kWh. A facility that used 1,200 MWh in a year while its IT equipment used 800 MWh has a PUE of 1.5. Use 12 months of energy for an annual figure.

Can PUE be less than 1?

No. Total facility energy always includes IT energy, so the ratio cannot fall below 1.0. Metrics that credit reused heat, such as ERE, can fall below 1.0, which is one reason they are kept separate from PUE.

What is ISO/IEC 30134-2?

The international standard that defines PUE, its measurement categories and how to calculate, report and interpret it. The current edition, ISO/IEC 30134-2:2026, was published on 16 January 2026 and replaced the 2016 edition and its 2018 amendment.

Where should IT energy be measured for PUE?

The EU regulation requires measurement at the output of every UPS that feeds IT equipment (category 1 in EN 50600-4-2), or at the PDU where there is no UPS. Measuring further downstream, at the PDU or server inlet, is more precise. Whatever you choose, state it with the number.

Why did my PUE get worse after we consolidated servers?

Much facility overhead is fixed, so removing IT load shrinks the denominator faster than the numerator. Total energy probably fell. Right size the UPS and cooling and PUE will recover.

Do EU data centres have to report PUE?

Data centres with 500 kW or more of installed IT power must report energy, water and other data to the European database every year, by 15 May, under the Energy Efficiency Directive and Delegated Regulation 2024/1364. The Commission calculates PUE, WUE, ERF and REF from that data rather than taking a PUE from the operator.

Does liquid cooling always lower PUE?

Usually, because warm water cooling needs much less chiller work. But fewer server fans also shrink IT energy, so the PUE gain can understate the real saving. Compare total kWh too.

Where Safeguard fits

Safeguard does not measure energy, monitor facilities, manage data center infrastructure or analyse firmware or hardware. The fit with PUE is indirect: the exporters that poll PDUs and BMCs, the scripts that compute PUE and the dashboards that chart it are ordinary software built from open source packages. Safeguard can scan those repositories, container images and SBOM files for known vulnerabilities in their dependencies (for example safeguard scan --dir . in the repository or safeguard scan --image <name> for the image) and show which projects carry a given component version. That matters because energy telemetry tools usually run on the management network, next to BMCs and PDUs, where a vulnerable dependency deserves attention before it becomes an incident.

PUE dashboards, PDU and BMC exporters and DCIM tools are built on open source libraries and container images, and they often run on the management network beside the most privileged interfaces in the room. The fit with energy metrics is indirect, but keeping those components on fixed versions is the same discipline as keeping the meters calibrated.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not energy metering or facility monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the container image that runs your PDU or BMC exporter, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know which monitoring images to rebuild after an advisory.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before any command that changes something, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same flow applies when a JavaScript dashboard that charts your monthly PUE needs a dependency bump.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A facilities or platform team can then ask, in plain language, which of its monitoring projects carry a vulnerable package, without granting more access than that question needs.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• ISO open data: deliverables metadata for the ISO/IEC 30134 series, including ISO/IEC 30134-2:2026 and 30134-2:2016
• ISO: ISO/IEC 30134-2:2016 catalogue entry (archived copy)
• EUR-Lex: Directive (EU) 2023/1791 on energy efficiency (recast)
• EUR-Lex: Commission Delegated Regulation (EU) 2024/1364 on the first phase of a common Union rating scheme for data centres
• European Commission: Energy performance of data centres
• European Commission: Frequently asked questions on the European database on data centres, version 1.9 (PDF)
• US DOE FEMP: Best Practices Guide for Energy-Efficient Data Center Design, revised July 2024 (PDF)
• US DOE FEMP: Energy efficiency in data centers
• US DOE FEMP / ORNL: High Performance Computing Data Center Metering Protocol, September 2010
• US DOE: DOE releases new report evaluating increase in electricity demand from data centers, 20 December 2024
• Lawrence Berkeley National Laboratory: 2024 United States Data Center Energy Usage Report (archived page)
• The Green Grid: PUE, A Comprehensive Examination of the Metric
• The Green Grid: home page
• DMTF Redfish: EnvironmentMetrics schema v1.3.0
• DMTF Redfish: PowerSubsystem schema
• Debian manpages: ipmitool(1)
• Linux kernel documentation: Power capping framework

Last reviewed: 25 October 2026. ISO/IEC 30134-2 was revised in January 2026 and the EU rating scheme and minimum performance standards are still in consultation; check the pages above for the current text before you cite a threshold or a category.