Data centre load bank testing uses controllable artificial electrical and thermal loads to prove that power and cooling systems perform to their design ratings before live IT equipment is installed. It is central to commissioning, from single-system functional tests to full integrated systems testing (IST) at Level 5.
Key takeaways
- Load banks apply controllable electrical and thermal load so power and cooling can be proven to design ratings before live IT is installed.
- Testing intensifies at commissioning Level 4 (individual systems) and Level 5 integrated systems testing (IST), which drives the whole facility through failure scenarios and can take 20+ working days.
- A/B feed testing proves each redundant path can carry 100% of load, validating the ~50% normal-loading rule and concurrent maintainability for Tier III/IV facilities.
- Use resistive load banks for kW/heat testing and resistive-reactive banks at 0.8 pf to prove full kVA rating; the reactive bank is sized at roughly 75% of the resistive kW.
- Server emulators simulate per-rack heat and airflow in the white space; ASHRAE recommends holding IT inlet temperatures around 18-27 C through normal and failure conditions.
- AI/HPC racks (e.g. ~132 kW GB200 NVL72) need liquid-cooled load banks that emulate both thermal load and hydraulic resistance to properly commission CDUs and direct-to-chip loops.
What is data centre load bank testing?
Data centre load bank testing is the practice of applying a known, controllable artificial load to a facility's electrical and cooling infrastructure so that its real-world performance can be measured and verified before any revenue-generating IT equipment is connected. A load bank converts electrical energy into heat through resistive elements (and, in reactive units, absorbs or supplies reactive power through inductors or capacitors), allowing engineers to draw a precise, repeatable load in kilowatts (kW) and kilovolt-amps reactive (kVAR) on demand.
The purpose is simple but critical: you cannot trust that a generator, uninterruptible power supply (UPS), power distribution unit (PDU) or cooling plant will hold up under full load unless you have actually loaded it. Load banks let commissioning teams stage load in defined steps, hold steady-state conditions, and trigger deliberate failures, all without risking live servers. This is why load banks are the workhorse tool across data centre commissioning.
Testing spans two domains. On the power side, load banks prove capacity, voltage and frequency stability, transfer times, battery autonomy and the ability of redundant paths to pick up load. On the mechanical side, the heat rejected by the load banks becomes a controllable heat source that proves the chillers, computer room air handlers (CRAHs) and, increasingly, liquid-cooling loops can remove the design heat load while holding IT inlet conditions within specification.
- Proves electrical capacity and stability under real load, not just nameplate assumptions
- Provides a controllable heat source to validate cooling capacity and redundancy
- Enables safe, repeatable failure simulation before live IT is at risk
- Generates documented evidence for commissioning sign-off and client handover
What are the data centre commissioning levels (L1 to L5)?
Data centre commissioning is structured into a sequence of levels, commonly numbered Level 1 through Level 5 (some frameworks add a Level 0 design review and a Level 6 closeout). Each level builds on the one before, progressively de-risking the facility, and load banks feature heavily from Level 4 onwards.
Load bank testing is most intensive at Levels 4 and 5. Level 4 loads individual systems, one generator or one UPS module at a time, while Level 5 links everything together and drives the whole facility through the failure scenarios it will one day have to survive. Level 5 IST on a large or complex facility routinely takes 20 or more working days, so mobilising the right load bank fleet is a significant part of the commissioning programme.
- Level 1 - Factory acceptance testing (FAT): equipment is witness-tested at the manufacturer before shipment
- Level 2 - Delivery, installation and pre-start checks: correct installation is verified and equipment is made ready to energise
- Level 3 - Start-up and site acceptance: each component is energised and started for the first time on site
- Level 4 - Functional performance testing: individual systems (a UPS, a generator, a chiller) are loaded and proven against design
- Level 5 - Integrated systems testing (IST): all systems run together and are subjected to real-world failure and recovery scenarios
What is integrated systems testing (IST) and how do load banks support it?
Integrated systems testing, the Level 5 stage, is the final and most demanding proof that a data centre's electrical, mechanical, controls and life-safety systems operate as one coordinated whole. Rather than testing a UPS or a chiller in isolation, IST runs the entire facility under load and deliberately breaks things: loss of utility power, loss of a UPS path, chiller trips, pump failures and CRAH failures, then observes whether the building management system (BMS) and electrical controls respond correctly and whether critical conditions are maintained throughout.
Load banks are what make IST possible. Because live IT cannot yet be exposed to these failure scenarios, load banks impose the facility's design electrical load and its design heat load simultaneously and steadily. Engineers typically stage the load in increments, for example loading in 25% steps up to 100% of design, to observe behaviour at part load and full load, and to mimic the way rack load ramps up as a hall fills.
A well-run IST proves the timing that matters: that the UPS carries the load through the gap while generators start and take over, that automatic transfer switches operate within their rated transfer time, and that cooling recovers quickly enough after a power event that IT inlet temperatures never breach the allowable envelope. The output is a documented body of evidence that the facility meets its Owner's Project Requirements before a single production server is switched on.
- Simulates utility loss, generator start, UPS ride-through and automatic transfer
- Tests coordinated response of electrical, mechanical, controls and fire systems together
- Applies design electrical and thermal load in steps (commonly 25/50/75/100%)
- Verifies cooling recovers after power transitions before IT inlet limits are breached
What is A/B feed testing and why does redundancy matter?
Modern data centres deliver power to each rack over two independent paths, referred to as the A feed and the B feed. In a true 2N design the entire electrical path is duplicated, independent transformers, UPS systems, distribution boards and PDUs, so that either path alone can carry the full load. In an N+1 design a single spare component is added beyond the base requirement. A/B feed testing proves these redundancy claims are real rather than theoretical.
Because each path must be able to carry the whole load, a key design rule is that in normal operation each 2N UPS runs at no more than roughly 50% of its capacity, leaving full headroom to absorb the entire load the instant the other path fails. Load bank testing is how this is verified: engineers apply full design load, then take the A path out of service and confirm the B path assumes the entire load with no interruption, no overload trip and no excursion in voltage or frequency, before restoring and repeating on the other path.
A/B feed testing also validates day-to-day operations, not just faults. Concurrent maintainability, the ability to take any part of the electrical system offline for maintenance without dropping the critical load, is demonstrated by shifting the whole load onto one path while the other is isolated as if for service. For Tier III and Tier IV facilities this concurrent-maintainability and fault-tolerance proof is a core deliverable, and it is only credible when performed at full load with load banks.
- Confirms each of the A and B paths can independently carry 100% of design load
- Verifies the ~50% normal loading rule that gives 2N systems their failover headroom
- Proves no interruption, trip or voltage/frequency excursion on path failover
- Demonstrates concurrent maintainability required by Tier III and Tier IV designs
Which load bank types are used, and why does power factor matter?
The right load bank depends on what is being tested. Resistive load banks apply a unity (1.0) power-factor load, drawing only real power (kW) as heat. They are ideal for exercising a generator's prime mover and its fuel and cooling systems, and for imposing a heat load on the cooling plant. However, a purely resistive test leaves the alternator's ability to supply reactive current, and the UPS's ability to handle a leading or lagging load, completely unproven.
Resistive-reactive load banks add inductive (and sometimes capacitive) elements so that testing can be performed at less than unity power factor, most commonly 0.8, which reflects how real generators and UPS systems are rated. Because most sets are rated at 0.8 pf, testing at that power factor proves the full kVA nameplate rather than just the kW. As a rule of thumb, to achieve a 0.8 pf test the reactive (kVAR) bank is sized at about 75% of the resistive (kW) bank. Specifications for Tier III and Tier IV facilities frequently mandate combined resistive-reactive testing at 0.8 pf.
Other variants serve specific plant. DC load banks test battery strings and rectifier/plant used in DC power systems, verifying autonomy at the rated voltage (VDC). Load banks are supplied for a range of voltages and both 50 Hz and 60 Hz systems, and should carry the appropriate safety and conformity marks (for example CE/UKCA in the relevant markets, with equipment designed to the applicable IEC and UL standards).
- Resistive (1.0 pf): tests kW capacity, prime movers and cooling; simplest heat source
- Resistive-reactive (typically 0.8 pf): proves full kVA rating and alternator/UPS reactive handling
- DC load banks: verify battery-string autonomy and rectifier plant at rated VDC
- Reactive bank sized at roughly 75% of the resistive kW to reach 0.8 pf
- Specify correct voltage, 50/60 Hz and relevant conformity marks (CE/UKCA, IEC/UL)
How is white-space heat load simulated with server emulators?
Beyond the central power plant, the data hall itself, the white space, must be proven to cool the racks it will host. This is done with rack-mounted load banks and server emulators that are placed in the racks and airflow paths exactly where real servers will sit, then set to dissipate a defined kW per rack. Assemblies commonly cover roughly 1 to 24 kW per rack for traditional air-cooled halls, and the airflow pattern (front-to-back, and hot-aisle/cold-aisle containment) is reproduced so the test reflects reality rather than an idealised load.
Heat-load testing (HLT) uses these emulators as a controllable, uniformly distributed heat source to prove the cooling system removes the design heat while holding server inlet temperatures within the ASHRAE thermal guidelines, whose recommended envelope for most IT classes is about 18 to 27 degrees C, with a wider allowable range. The test is run at design load and through cooling failure scenarios, chiller trip, pump failure, CRAH/CRAC failure and loss of a cooling path, to confirm inlet limits are never breached and that cooling recovers after a power transition.
A conventional load bank only forces heat through the space. A modern server emulator goes further by reproducing the physical footprint, airflow resistance and, for liquid systems, the hydraulic behaviour of a real server, so that cooling distribution and pressure profiles across the hall match live operation far more closely.
- Rack-level emulators dissipate a set kW per rack in the real rack position and airflow path
- Typical air-cooled rack simulation spans about 1-24 kW with correct front-to-back airflow
- Validates inlet temperatures against ASHRAE guidance (recommended ~18-27 C)
- Exercises chiller, pump, CRAH and cooling-path failure scenarios and recovery
How are liquid-cooled load banks used for AI and HPC data centres?
AI and high-performance computing (HPC) racks have pushed heat densities far beyond what air can remove. Current-generation accelerated racks such as NVIDIA's GB200 NVL72 draw on the order of 132 kW per rack, of which the large majority (around 115 kW) is rejected to liquid via direct-to-chip cold plates, with only a small remainder handled by air. At these densities the object of commissioning is no longer just the air-side cooling but the liquid-cooling loop and its coolant distribution units (CDUs).
Liquid-cooled load banks and rack emulators address this by rejecting their heat into the coolant loop rather than into the air. They connect to the technology cooling system and let engineers impose a controllable thermal load on the CDU and secondary loop, verifying flow rate, supply and return temperatures, approach temperature and pressure across the design range. CDUs themselves span a wide capacity range, from a few hundred kW in a rack-mounted unit up to multi-megawatt floor-standing systems, and come in liquid-to-liquid (L2L) and liquid-to-air (L2A) configurations, each of which must be commissioned under representative load.
The critical advance for AI commissioning is emulating hydraulic resistance as well as heat. A cold plate presents a specific flow-versus-pressure characteristic; a device that only injects heat will not load the CDU's pumps and control loops the way a real GPU tray does. Purpose-built liquid load banks and rack emulators reproduce both the thermal load and the hydraulic resistance of a populated rack, which is what allows a CDU's true performance, and its behaviour under partial-loop failure, to be validated before live AI hardware is installed.
- AI racks (e.g. GB200 NVL72) reach ~132 kW, mostly rejected to liquid via direct-to-chip cold plates
- Liquid load banks impose controllable thermal load on the CDU and secondary loop
- Verify flow rate, supply/return and approach temperatures, and loop pressure
- Emulating hydraulic resistance (not just heat) is essential for true CDU validation
- Applies to direct-to-chip and immersion cooling for HPC and AI clusters