The short version: N+1 redundancy for CRAH units is calculated in capacity, not airflow, and the two numbers diverge exactly when a unit fails. The surviving units can meet the room’s total cooling load on paper while individual racks drift out of range for minutes, because nothing about a capacity count guarantees the leftover airflow lands where the heat actually is. The fix is not more redundant units; it is measuring what happens in the minutes after a failover, not just before one.

What N+1 actually specifies for CRAH units

A computer room air handler pulls warm return air across a chilled-water coil and pushes it back out cooled, with the actual refrigeration happening upstream at a central chiller plant. That’s the detail that separates a CRAH unit from a CRAC unit, which carries its own compressor. Because CRAH units are simpler machines, drawing on shared chilled water rather than running independent refrigeration circuits, they scale cheaply: add another air handler to the same chilled-water loop and you’ve added capacity.

N+1 redundancy for a CRAH-cooled data center is a straightforward exercise in that arithmetic. If a hall needs five 300kW units to handle its IT heat load, a sixth is installed so that any single unit can fail, or come down for maintenance, without dropping below the required capacity. Uptime Institute’s own analysis of CRAC/CRAH redundancy math shows how directly the tradeoff scales: moving from N+1 to N+2 buys additional fault tolerance at a real cost in floor space and cabinet density per square foot (Uptime Institute, “Data Center Cooling: CRAC/CRAH redundancy, capacity, and selection metrics”). That framing is correct as far as it goes. It is also where most treatments of CRAH redundancy stop.

The chilled-water dependency the capacity math skips

A CRAH unit is only as redundant as the chilled-water plant feeding it. The air handler itself can be sitting idle and fully functional and still deliver zero cooling if the supply header, a valve, or the chiller loop it depends on is degraded. Redundancy planning that stops at “how many air handlers do we have” is planning around the wrong constraint, because the single point of failure usually isn’t the fan and coil assembly in the room. It’s upstream, in a piping and pump system the N+1 spec sheet never mentions.

This matters for how a facility actually recovers. Two air handlers rated N+1 on capacity share one chilled-water plant behind them. If that plant is itself running at or near its own limit, adding a redundant CRAH unit adds standing hardware without adding usable thermal headroom.

What happens in the minutes after a CRAH unit fails

Here is the part that capacity-based redundancy planning consistently leaves out: what the room looks like in the interval between a unit going down and the space re-stabilizing. A failed CRAH unit doesn’t just subtract its rated tonnage from the room total and let the remaining units absorb the difference instantly. It removes a specific airflow path, a return grille location, a discharge point, a piece of the room’s pressure balance, and the racks that unit was serving nearest are the ones that feel it first.

The surviving units don’t redirect their output toward the newly under-cooled racks on their own. They respond to their own local return-air sensor, which may read normally for a minute or more while heat builds two or three rows away. Meanwhile, the failed unit’s stalled fan can become a short-circuit path for hot exhaust air to recirculate back into the cold aisle, undoing part of what the working units are still delivering. None of this shows up in a redundancy diagram, because a diagram shows unit count, not airflow paths under a failure condition.

Why the survivors can work against each other

Multiple CRAH units on a shared floor are also, in effect, multiple independent thermostats competing for the same air mass. Under normal load they settle into a stable pattern because nothing is forcing a correction. The moment one unit drops out and its neighbors ramp up to compensate, that stability is exactly what gets disturbed: one unit’s fan speed increase changes the pressure field the next unit over is sensing, which changes its own control response, and so on. Facilities engineers who have chased a hot spot that “moves” between racks over the course of an hour after a cooling event are usually watching this play out, without a tool that names it as the cause.

None of the standard references on CRAH selection or redundancy address this coordination problem directly, because it isn’t a capacity question. It’s a controls question, and it only appears at the moment the system stops behaving like N independent parallel devices and starts behaving like a system with one fewer degree of freedom than it had a minute earlier.

The metric that predicts a real failover, not just a paper one

If the goal is knowing whether a data center’s cooling will actually hold during a CRAH failure, the unit count is the wrong number to stare at. Two better ones:

  • Per-rack delta-T (exhaust minus intake), tracked continuously. A widening delta-T at a specific rack during normal operation is an early signal that airflow near that rack is already marginal, before any unit fails. That is the rack that will go out of range first when redundancy gets tested for real.
  • Time-to-recovery under a simulated failover. Taking one CRAH unit offline deliberately, during a maintenance window, and measuring how long the affected racks take to return to their normal operating band is a direct test of the thing N+1 is supposed to guarantee. A facility that passes on paper can still take eight or ten minutes to stabilize a rack, which is a meaningful gap if that rack is running latency-sensitive equipment.

Both numbers require instrumentation at the rack, not just at the room level, which is precisely the resolution a unit-count redundancy spec doesn’t require and therefore often doesn’t have.

What to check before trusting the redundancy spec

An N+1 CRAH configuration is a legitimate and necessary piece of data center design, and none of the above argues against installing one. The point is narrower: N+1 answers “do we have enough total cooling capacity,” and it was never built to answer “will this specific rack stay in range during the failure.” Those are different questions, and only the second one predicts what actually happens to the equipment.

Before treating a CRAH redundancy spec as resilience, it’s worth confirming the chilled-water plant behind it has its own headroom and failover path, and running an actual failover test with rack-level temperature logging rather than relying on the design document alone. The gap between “N+1 is satisfied” and “the racks stayed in range” is exactly the gap that shows up during a real outage, and it’s measurable well before one happens.