Data centre BMS alarm management is the work of deciding which of the thousands of possible alarms from CRACs, chillers, UPS, PDUs and environmental sensors actually need a human, at what priority, and how fast. The benchmark is EEMUA 191: an average of fewer than one alarm per ten minutes in steady state is acceptable, one per five minutes is manageable, and more than one per minute is unworkable. Plenty of data centre BMS alarm lists are nowhere near that.
Picture the call at three in the morning. “High temperature alarm, data hall 2.” The engineer drives in. The cold aisle is at 24°C, exactly where it sits every night since the containment went in. The alarm threshold is 23°C, because whoever set it up used the same limit they'd use for an office floor. It has fired most nights for months. Nobody has changed the threshold because nobody is sure who owns it. And the one time the same alarm means a real CRAC failure, it gets acknowledged along with all the others.
That's the alarm-management problem in a data centre, and it isn't a software problem. When a site ends up copying BMS alarms by hand into a daily spreadsheet just to keep a record, the alarm list has stopped being a safety system and become admin.
The two original cooling-tower fan drives at Park Royal, since removed and replaced by eighteen EC fans. A drive like this can raise dozens of fault codes. The alarm-management question is which of them the BMS should pass on, and at what priority.
What is BMS alarm management in a data centre?
It's the process of turning every alarm the plant is capable of raising into a short list of alarms that mean something, and making sure each one reaches the right person at the right speed. The reference framework is ANSI/ISA-18.2, written for process plants and directly usable in a data centre. Its lifecycle starts with an alarm philosophy document (what qualifies as an alarm, how priorities are assigned, what the performance targets are), then rationalisation, where every candidate alarm is judged against that philosophy one by one, then detailed design, implementation, operation and monitoring.
Rationalisation is where the value sits and where the time goes. For every alarm you ask: what is the consequence if nobody responds, how long has the operator got to respond, and what should they do? If there is no operator action, it isn't an alarm — it's an event, and it goes to a log, not the alarm banner. ISA-18.2 recommends three or four priority levels and no more than 5% of alarms configured at the highest priority. When priorities are left at manufacturer defaults, everything ends up “critical”, which means nothing is.
Which data centre BMS alarms actually matter?
The useful answer is system by system, because each part of the plant fails in its own way.
Cooling alarms: CRACs, chillers and cooling towers
On a CRAC or CRAH, the alarms that need a human are unit failure with no standby available, supply air temperature outside the design band with the trend rising, loss of chilled water flow, and water detected in the condensate tray or under the unit. A single filter-differential alarm on one of eight units is maintenance, not an emergency. On chillers, compressor trips and low refrigerant pressure matter; a high-oil-temperature warning on a unit that has just started does not. On cooling-tower fans — the eighteen EC fans we installed at Park Royal are a good illustration of the principle — with nine fans per cell, losing one fan is a different event from losing a whole cell. A well-designed strategy knows the difference, which means it counts healthy fans rather than just reporting each fan's status.
Electrical alarms: UPS, PDUs and generators
UPS on battery is the alarm that matters most in the building, because it starts a clock. Battery low, bypass active, output overload and inverter fault sit alongside it. On PDUs and busbar tap-offs, branch circuit trips and phase imbalance beyond design limits matter; a per-circuit load warning at 70% does not need a phone call at night. Generator fail-to-start on a mains loss is the one that goes to everyone. Our BMS vs DCIM vs EPMS guide covers who owns which of these alarms, because on a lot of sites the BMS is not the system watching the electrical side at all.
Environmental alarms: temperature, humidity and leaks
The ones that matter are rack inlet temperature above the allowable envelope, humidity outside limits, and any leak detection activation. Leak alarms should always be high priority: water under a raised floor is the one fault that turns into a very expensive one while everyone is still discussing it. Our data centre leak detection guide covers the sensing design; the alarm side is simple — it goes to the top of the list and it never gets auto-acknowledged.
A raised-floor void with basket tray going in, before the cables. Leak detection and underfloor sensors live down here, out of sight, which is why their alarms have to be trusted.
Why do comfort thresholds cause data centre alarm floods?
Because the numbers were set for a different building.
A commercial BMS engineer's instinct is to alarm a space at a degree or two off setpoint. That is right for an office, where the point of the BMS is comfort. In a data centre, the point of the BMS is to keep IT equipment inside its thermal envelope, and that envelope is defined by ASHRAE TC 9.9. The recommended server inlet range is 18–27°C; the allowable A1 envelope is 15–32°C and A2 is 10–35°C. A cold aisle sitting at 25°C is inside the recommended range. A high-temperature alarm at 23°C is a comfort threshold applied to thermal-protection equipment, and it will alarm every night the containment does its job.
The fix is to set thresholds against the envelope, not the setpoint: a warning where the inlet leaves the recommended range with a rising trend, a high-priority alarm as it approaches the allowable limit, and a deadband and time delay on both so a door opening doesn't page anyone. That's a rationalisation decision, written into the philosophy, applied to every sensor consistently, and on a badly configured site it can remove a large share of the temperature alarms in one pass.
Get a Free BMS Survey
We'll assess your controls and provide a detailed quotation.
How do critical alarms get lost?
The same patterns turn up on site after site.
Manufacturer defaults were never touched
The CRAC arrived with forty alarm codes enabled; the integrator mapped all forty into the BMS at the same priority. The UPS network card sends every SNMP trap it can generate. Nobody rationalised any of it because the commissioning programme had no line for it.
Chattering alarms with no deadband
A sensor sitting on its threshold, with no deadband, raising and clearing every thirty seconds. One point can generate hundreds of alarms a day on its own. EEMUA 191 counts these in the rate, and one chattering point can take a site from “acceptable” to “unworkable” by itself.
One fault raises fifteen alarms
A chiller trips, and the BMS raises the chiller alarm plus the low-flow alarm plus the high chilled-water temperature alarm plus the CRAC supply-temperature alarms on every unit fed by it. One cause, fifteen alarms, and the one that names the cause is buried in the fourteen that describe the consequence. ISA-18.2 calls the fix state-based alarming or designed suppression, and it has to be built into the strategy, not bolted on.
Every alarm goes to everyone
The same alarm list goes to the FM, the night technician, the M&E contractor and the client's operations manager by email, so nobody owns it and every alarm is somebody else's. The same goes for the sensors: someone has to be responsible for calibrating the meters and temperature sensors those alarms depend on, and that responsibility belongs in a contract.
Nobody has measured the alarm rate
The site doesn't know it has an alarm problem because nobody has ever counted. The sensible first step is a fortnight of raw alarm data from the head end, sorted by point. EEMUA 191 and ISA-18.2 both treat a short list of “bad actor” points as a normal finding, and fixing those first is where the quickest gains are.
The Park Royal cooling tower with its rooftop enclosure and local isolators. A local isolator turned off for maintenance should raise a maintenance-state alarm, not an equipment-failure alarm — that distinction is alarm management.
What standards apply to data centre BMS alarm management?
Two alarm standards, one thermal standard and one data centre standard.
EEMUA 191 (Alarm Systems: A Guide to Design, Management and Procurement) is the UK benchmark. Its steady-state guidance: fewer than one alarm per ten minutes per operator is very likely acceptable, one per five minutes is manageable, one per two minutes is likely over-demanding, and more than one per minute is very likely unacceptable. During an upset, it suggests the peak rate should not exceed ten alarms in ten minutes. Those numbers are the test you hold your alarm list against, and they translate to roughly 150 alarms a day in normal operation as the ceiling.
ANSI/ISA-18.2 (with its international equivalent IEC 62682) supplies the lifecycle: philosophy, identification, rationalisation, detailed design, implementation, operation, maintenance, monitoring, management of change and audit. It recommends no more than three or four priority levels and no more than 5% of alarms at the highest priority. Priority inflation — marking things critical without consequence analysis — is the most common rationalisation finding, and data centres are no exception.
ASHRAE TC 9.9 supplies the thresholds for the thermal alarms, as above. And BS EN 50600-2-3:2019 sets the environmental-control requirements by space and availability class, which means the alarms that protect those conditions should be traceable to the class the facility was designed to. A site designed to availability class 3 with a single-alarm-to-single-email routing hasn't matched its alarm handling to its design intent.
What does good data centre alarm management look like?
It looks like a short list, a written philosophy, and a measured rate.
The philosophy document exists, it's a few pages, and it says what an alarm is, what the priorities mean in terms of response time, and who owns each system's alarms. Every alarm on the head end can be traced to a line in the rationalisation record with a consequence and an operator action. Thresholds are set against the ASHRAE envelope and the plant's protection limits, with deadbands and delays. Consequence alarms are suppressed when the cause alarm is active. Routing is by priority and by system: the UPS-on-battery alarm reaches the people who can do something about it, and the filter-change reminder reaches the maintenance planner. The rate is measured monthly against EEMUA 191 and the top-ten points are reviewed.
And it's tested. Every high-priority alarm has been simulated at least once during commissioning and again after any major change, with the route to the responder proven end to end — not just “it appeared on the graphic”. If the BMS is being integrated or replaced, alarm rationalisation belongs in that programme, which is why we treat it as part of data centre BMS integration rather than a separate exercise afterwards.
When should you rationalise your data centre BMS alarms?
If your engineers are acknowledging alarms without reading them, now. If the night-shift technician found a real fault by walking the hall rather than from the head end, now. If you can't say who owns UPS alarms versus cooling alarms, now. And before any new BMS, DCIM or EPMS platform goes in, because migrating a bad alarm list onto a new system just makes it faster.
The commercial reality is that alarm rationalisation is engineering time spent on alarm data you already have. The alternative is paying callout rates for false alarms and carrying the risk that the real one is missed. Our BMS maintenance contracts guide covers how alarm review fits into ongoing support.
Getting the alarm list back under control
Alarm management in a data centre isn't about having more alarms or fewer. It's about having the right ones, at the right priority, going to the right person, and being able to prove it with a rate. Alpha Controls review and re-engineer BMS alarm strategies on Trend, Distech, Siemens and Schneider systems across London and the South East. If your alarm list has stopped being trusted, get in touch or request a quote for an alarm review.
Alpha Controls Team
Specialist BMS installation, commissioning, and maintenance across London and the South East. SafeContractor Approved, BCIA Member.
