ASHRAE’s X-factor is a reliability lens for warmer setpoints; liquid cooling is the engineering response when rack heat flux makes air the limiting factor.
Executive Summary
- ASHRAE TC 9.9’s X-factor is not a cooling method; it is a normalised hardware-failure-rate ratio that quantifies reliability impact as inlet temperature rises from a baseline.
- Raising supply-air or inlet setpoints typically increases the X-factor (more expected failures) but can unlock a disproportionate increase in economiser hours and lower compressor lift in temperate climates.
- For AI data centre cooling, the binding limit is often rack heat flux and airflow practicality: at ~30–100+ kW/rack, air cooling becomes difficult regardless of how wide the allowable temperature envelope is.
- Liquid cooling breaks into distinct families with different plant implications: direct-to-chip (cold plates), rear-door heat exchangers (transitional), and single- or two-phase immersion (highest heat capture, biggest operational change).
- Cooling optimisation is increasingly a boundary-definition exercise: what is inside the PUE boundary, and where does heat reuse or heat pumping sit relative to ISO 30134 reporting.
- A credible strategy couples reliability modelling (X-factor lens), thermodynamic feasibility (heat rejection and ΔT), and operational readiness (chemistry, leak detection, maintainability) rather than chasing a single metric.
Why the X-factor is being revisited now
The current cooling conversation is being driven by two pressures that look similar on a PUE dashboard but behave very differently in engineering terms. First, energy and carbon scrutiny is pushing operators to run warmer and to maximise economiser (free cooling) hours. Second, AI clusters are concentrating heat in ways that make airflow, coil approach temperatures, and fan power the practical limit long before the site runs out of floor area.
ASHRAE TC 9.9’s X-factor sits in the first pressure. It is a statistical reliability metric: a normalised failure-rate ratio relative to a baseline inlet temperature. It helps quantify the reliability impact of raising setpoints. It does not move heat. Liquid cooling sits in the second pressure: it changes the heat-transfer path so high-density racks remain thermodynamically feasible.

This article is written for engineers and technical decision-makers who need to make data centre cooling choices defensible: what to do with setpoints and envelopes, when liquid cooling becomes unavoidable, and how to avoid metric-driven decisions that fail in operations. For broader context on Azura’s data centre work, see data center consultants.
What ASHRAE’s X-factor actually represents (and what it does not)
ASHRAE’s Thermal Guidelines for Data Processing Environments define environmental envelopes (commonly referenced as A1–A4 classes) and provide a way to discuss “allowable” versus “recommended” operating bands. The X-factor is a separate but related construct: it expresses how expected hardware failure rates change as inlet temperature moves away from a baseline condition.
How to use it in engineering decisions
Used properly, the X-factor is a decision lens: it makes the reliability cost of a warmer setpoint explicit so it can be weighed against energy savings, maintenance strategy, and service-level risk. It is most useful when paired with an equipment population model (what is deployed, for how long, with what replacement policy) rather than as a single headline number.

Common misread: “X-factor cooling”
The X-factor does not tell a site how to cool. It does not replace airflow management, coil selection, chilled-water temperature strategy, or controls. And it does not remove the thermodynamic constraint that, at some rack heat loads, the air mass flow required becomes operationally impractical (fan power, noise, containment leakage tolerance, and serviceability).
Setpoints, economisers, and the real trade-off behind “run hotter”
The engineering argument for warmer supply air is straightforward: higher chilled-water temperatures reduce lift, improve chiller efficiency, and widen the ambient window where air-side or water-side economisers can carry load. In many temperate European climates, moving a design target from ~22°C towards ~27°C at rack inlet can materially increase economiser hours, because the number of hours below the higher threshold rises faster than linearly.
What typically limits the upside

- Reliability and warranty posture: the X-factor increases as inlet temperature rises; the practical question is how much additional failure exposure is acceptable over the refresh cycle.
- Humidity and latent control: warmer air can reduce relative humidity margin depending on site strategy; if dehumidification or humidification energy rises, the net gain shrinks.
- Air distribution and containment: higher ΔT assumptions can be undermined by bypass and recirculation; the “average” inlet number may hide hot spots that drive throttling.
- Controls stability: aggressive setpoint resets can cause hunting between economiser and mechanical modes, increasing wear and undermining predicted savings.
This is where PUE often misleads. PUE reports the facility overhead, but it does not report the reliability penalty implied by the X-factor, nor does it tell whether the thermal margin is evenly distributed. For wider efficiency context and how PUE trends are interpreted, see PUE trends.
When air cooling stops being the main lever: heat flux and high-density racks
The X-factor discussion assumes the facility can deliver the target inlet condition in the first place. For conventional enterprise densities, that is often true. For AI data center cooling, the facility is increasingly asked to support dense GPU rows where the limiting factor is not “can servers tolerate 27°C”, but “can the room deliver enough air mass flow without unacceptable fan power, noise, and hot-spot risk”.
The practical failure modes in high-density air

- Fan power becomes a material fraction of IT power as airflow is pushed; the efficiency curve is unforgiving at the extremes.
- Containment leakage and bypass air turn from “efficiency loss” into “thermal runaway risk” because the margin per rack is small.
- Coil approach temperatures and heat-rejection limits dominate: even if the hall is controlled, the plant may not reject heat without high condensing temperatures.
- Serviceability suffers: higher face velocities and tighter containment make routine work harder and increase the chance of human-induced disturbances.
The driver is workload profile and density, not branding. A useful framing is whether the deployment resembles an AI data hall more than a conventional enterprise hall; AI data centres covers the facility-level differences that typically show up first.
Liquid cooling options: direct-to-chip, rear-door, and immersion (engineering view)
Once rack density pushes beyond what air can move comfortably, the choice is not “air versus liquid” in the abstract; it is which liquid topology matches the deployment, the building constraints, and the operator’s maintenance model.
Direct-to-chip (DLC) cold plates
DLC places cold plates on CPUs/GPUs and uses a coolant distribution unit (CDU) to couple the IT loop to a facility water loop. It is common to retain air cooling for memory, storage, and power supplies. The engineering work is hydraulic (flow, pressure drop), controls (supply temperature reset, dewpoint management), and chemistry (water quality, inhibitors). Azura’s deeper primer on DLC is in direct-to-chip liquid cooling.
Rear-door heat exchangers (RDHx)

RDHx sits on the rack exhaust and removes a large portion of heat before it returns to the room. It is often a transitional approach for retrofitting existing air-cooled halls because it preserves server form factors and much of the operational pattern. The constraints are rack weight, door serviceability, water routing, and condensation control if very cold water is used (many designs avoid this by running warmer water).
Immersion (single- and two-phase)
Immersion places IT hardware directly in a dielectric fluid. Single-phase immersion circulates warmed fluid through a heat exchanger; two-phase uses boiling and condensation. Immersion can capture a very high fraction of IT heat in a controlled loop, which can be attractive for heat reuse. It also changes maintenance workflow, hardware qualification, and fluid handling. The operational shift is often the deciding factor, not the physics.
Integration risks that decide whether liquid cooling works in operations
Liquid cooling programmes that struggle usually do so because the thermal concept was sound but the integration detail was weak. The failure mode is rarely “heat cannot be moved”; it is “the system cannot be operated and maintained without unacceptable risk”.
What needs explicit design ownership

- Interface definition: who owns the boundary between IT loop and facility loop (temperatures, pressures, water quality, alarms, and acceptance tests).
- Water chemistry and corrosion control: conductivity targets, inhibitor strategy, filtration, sampling regime, and response plan for excursions.
- Leak detection and isolation: sensors, zoning, automatic valve closure philosophy, and how to avoid nuisance trips that take out whole rows.
- Maintainability: drain-down points, spill containment, safe access, and whether routine IT work can be done without disturbing hydraulics.
- Controls: stable supply temperature reset, dewpoint awareness (where relevant), and clear fallback modes for partial failures.
Where heat reuse is in scope, liquid cooling also changes the quality of recoverable heat. Higher leaving-water temperatures can make downstream reuse more practical; data center heat reuse covers the engineering and metric implications.
Metrics and boundaries: aligning X-factor thinking with PUE and heat reuse reporting
Engineering teams are often asked to “improve PUE” and “enable heat reuse” while also being told to hold availability risk flat. Those are not contradictory goals, but they require boundary clarity and explicit trade-offs.
Three lenses that need to be kept separate
- Efficiency lens: PUE captures facility overhead but is sensitive to what is counted inside the boundary and to operating regime (part-load versus design).
- Reuse lens: ERF/ERE improve when heat is exported, but the placement of heat pumps and metering points changes the reported outcome.
- Reliability lens: X-factor expresses the relative failure-rate impact of warmer inlet temperatures; it is not visible in PUE/ERF reporting and needs to be documented alongside them.
For how boundary choices affect PUE and ERF when heat pumps are used to upgrade waste heat, heat pump placement and ISO 30134 boundaries provides a detailed treatment aligned to ISO 30134.
Decision Framework: choosing setpoints and cooling topology using three constraints
The fastest way to avoid “metric chasing” is to structure the decision around constraints rather than preferences. The framework below is designed to produce a defensible recommendation that can survive design review, procurement, and operations handover.
Constraint 1 — feasibility (physics and plant)
- Input: target rack densities by zone (average and peak), allowable ΔT, containment effectiveness, and heat-rejection limits.
- Test: can air cooling deliver the required air mass flow without unacceptable fan power and hot-spot risk? If not, liquid is required regardless of setpoint.
- Output: minimum viable cooling topology set (air, RDHx, DLC, immersion) for each deployment zone.
Constraint 2 — reliability posture (X-factor lens)
- Input: proposed inlet setpoint and excursion policy, equipment class and refresh cycle, and service-level risk tolerance.
- Test: what relative failure-rate increase is implied versus baseline, and is it acceptable given spares strategy and maintenance model?
- Output: recommended operating band (recommended vs allowable) with an explicit reliability rationale.
Constraint 3 — operational readiness (people and process)
- Input: maintenance workflow, staffing model, vendor support, and site constraints (water treatment, safety, spill management).
- Test: can the organisation operate chemistry control, leak detection/isolation, and component service without increasing human-error risk?
- Output: readiness gaps list (procedures, monitoring, training, spares) that must be closed before scale-out.
Validating a cooling strategy for higher densities?
Azura supports operators and developers with feasibility, MEP integration, and commissioning planning for air and liquid-cooled data centre environments.
What this requires from design and delivery teams
In delivery terms, the “X-factor” conversation is a governance and controls problem: setpoints, excursions, and economiser changeover need to be stable, documented, and aligned with the IT estate’s warranty and refresh posture. Liquid cooling is an integration problem: it introduces new interfaces (CDUs, secondary loops, leak detection, chemistry) that must be designed as part of the facility, not bolted on at rack deployment.
Azura supports operators, developers, and colocation providers by translating cooling strategy into engineering deliverables: concept and options studies, MEP design integration, controls philosophy, commissioning and validation planning, and technical due diligence where cooling feasibility is a gating risk. Related work often touches adjacent sustainability questions such as water strategy and discharge constraints, including zero liquid discharge considerations.
Practical first moves for an active cooling programme
- Separate the questions: (1) what inlet setpoint and envelope is being targeted, and (2) what rack densities require liquid regardless of setpoint.
- Document an X-factor posture: baseline condition, proposed operating band, excursion policy, and how reliability risk is managed (spares, refresh, warranty alignment).
- Map densities by zone and time: peak racks, average racks, and expected growth path; avoid designing only to a site-wide average.
- Choose a liquid topology for a pilot based on operational readiness (service model, chemistry, leak response), not just thermal performance.
- Define the IT–facility interface in writing (temperatures, pressures, alarms, acceptance tests) before procurement locks in incompatible vendor assumptions.
- If heat reuse is in scope, decide early where the reporting boundary sits and how metering will be implemented so PUE/ERF claims are auditable.
Conclusion
ASHRAE’s X-factor is best understood as a reliability accounting tool for warmer inlet setpoints: it quantifies the failure-rate trade-off that sits behind “run hotter” strategies and helps make economiser and chiller-lift decisions defensible. It is not a cooling technology, and it cannot solve the physical limits of moving large heat loads with air.
Liquid cooling addresses a different problem: the feasibility of high-density racks and AI-focused deployments where airflow and fan power become the binding constraint. The practical engineering work is in integration and operations—interfaces, hydraulics, chemistry, leak management, and controls—so that efficiency gains do not come at the cost of availability.
FAQ
what technologies are available for capturing and repurposing waste heat generated by data center cooling systems?
The main options are air-to-water or water-to-water heat exchangers on the cooling loops, often paired with heat pumps to raise temperature for district heating or building HVAC. Liquid cooling can increase the usable heat grade by delivering warmer, more stable water temperatures. The viability depends on nearby heat demand, temperature requirements, metering, and how the reuse boundary is defined for ISO 30134 reporting.
what are the best heat transfer fluid solutions offering proven roi for data center pue reduction and equipment longevity?
There is no universal “best” fluid: ROI and longevity depend on topology (direct-to-chip water loops versus dielectric immersion), materials compatibility, corrosion control, and maintenance discipline. For water-based loops, the engineering focus is chemistry management (conductivity, pH, inhibitors), filtration, and monitoring. For dielectric fluids, the focus shifts to fluid stability, compatibility with components, and service procedures. “Proven ROI” is usually site- and workload-specific rather than intrinsic to a fluid.
how much power does a data center use
Power draw is typically discussed at two levels: IT load (servers, storage, network) and total facility load (IT plus cooling, power conversion, lighting, etc.). The ratio between them is captured by PUE. A facility’s absolute MW depends on the deployed IT and utilisation profile, while the overhead depends heavily on cooling topology, climate, and operating setpoints. For AI-heavy deployments, the limiting factor is often localised density rather than total floor area.
Cooling decisions now shape the facility.
Where setpoints, liquid cooling, or heat reuse materially affect risk and programme, Azura can support technical due diligence and design validation across the delivery lifecycle.
References
- Thermal Guidelines for Data Processing Environments — ASHRAE Technical Committee 9.9 (2021-01-01)
- ISO/IEC 30134 — 2: Information technology — Data centres — Key performance indicators — Part 2: Power Usage Effectiveness (PUE) — ISO/IEC (2016-01-01)
- ISO/IEC 30134 — 6: Information technology — Data centres — Key performance indicators — Part 6: Energy Reuse Factor (ERF) — ISO/IEC (2021-01-01)
- Liquid Cooling Technologies for Data Centers (technology overview and adoption considerations) — Uptime Institute (2023-06-01)









