There is a moment we see on nearly every building assessment we do. We sit down at the BAS front end with the facilities manager, open the alarm console, and see hundreds or thousands of unacknowledged alarms stretching back weeks or months. We ask when they last looked at the alarm log. They shrug and say they stopped paying attention to it because it just never stops.
That is alarm fatigue. And it is not a personnel problem. It is a system design problem.
A building automation system that generates hundreds of alarms per day is not doing its job. Alarms are supposed to be actionable signals that something requires attention. When alarms are ignored, real problems get missed, equipment fails unnecessarily, occupants are uncomfortable, and the entire value of having a BAS is undermined. The system becomes expensive wallpaper.
Why Alarm Fatigue Happens
The root cause is almost always the same: alarm setpoints and routing configurations were set up during commissioning and never revisited. The original setup was done under time pressure, the contractor left, and nobody with the knowledge or access to adjust the system came back.
Common sources of the problem:
Setpoints too tight or poorly chosen. A temperature alarm configured to fire any time a space deviates more than 1 degree from setpoint will fire constantly in any building with normal load variation. An alarm that fires any time a piece of equipment is in its scheduled off state will fire every night. These alarms are technically correct but operationally useless.
No prioritization. When a chiller fault alarm looks identical to a differential pressure transmitter alarm that fires every time a filter loads up, operators cannot quickly identify what actually matters. Everything blurs together.
No routing or routing gone stale. Alarms configured to go to an email address or phone that nobody checks anymore are the same as alarms that go nowhere. We find this constantly: routing lists with former employees, decommissioned email groups, and phone numbers for technicians who left the company years ago.
Nuisance alarms from bad sensors or intermittent equipment. A temperature sensor that reads erratically due to a loose wire will generate alarms every time it reads out of range. If that sensor generates 50 alarms per shift, operators learn to tune it out, along with everything else.
No suppression during maintenance. When your HVAC technician takes a unit offline for scheduled maintenance, alarms for that unit should be suppressed for the duration. If they are not, the alarm log fills up with expected events, further training operators to ignore it.
The Fix: Alarm Rationalization
Alarm rationalization is the process of systematically reviewing every alarm in your system and making a deliberate decision about each one: is this alarm necessary, is it actionable, is its setpoint appropriate, who should receive it, and how should they receive it?
This is not glamorous work. It involves sitting with a spreadsheet and going through your alarm list item by item. But it is the single most impactful thing most building owners can do to restore confidence in their BAS.
For each alarm, the rationalization process answers:
- Is this alarm event actually a problem worth acting on? If the answer is no, disable the alarm or change it to a log-only event.
- Is the setpoint appropriate? Does the threshold reflect a genuinely abnormal condition, or is it so tight that it fires under normal variation?
- Is this alarm something an operator can actually act on? An alarm for a sensor failure is only useful if there is a process for getting that sensor checked and replaced. An alarm for a setpoint deviation is only useful if an operator has the access and knowledge to investigate and correct it.
- What priority should this alarm carry?
Building a Useful Alarm Priority Structure
A workable priority structure typically uses four or five levels. Here is the framework we implement for most clients:
Critical (Priority 1): Life safety, equipment-damaging conditions, or building-wide system failures. Examples: fire alarm integration signals, chiller high-pressure lockout, freeze stat trips, total loss of cooling in a data center or critical healthcare area. These alarms go directly to cell phones via text or automated phone call, 24 hours a day, 7 days a week.
High (Priority 2): Significant equipment faults or comfort failures affecting large areas. Examples: air handler supply fan failure, major valve failing open or closed, entire floor with no cooling during occupied hours. These also go to cell phones during occupied hours, and to on-call personnel after hours.
Medium (Priority 3): Equipment anomalies that require investigation but are not immediately critical. Examples: zone temperature deviation exceeding 4 degrees for more than 30 minutes, filter differential pressure reaching replacement threshold, cooling tower level low. These go to email with a 4-hour response expectation during business hours.
Low (Priority 4): Informational events and minor deviations. Examples: schedule overrides left active for more than 24 hours, sensor readings at the edge of normal range, communication loss to a non-critical device. These go to a daily or weekly email digest for review.
Info (Priority 5): Log-only events. System state changes, setpoint modifications, user logins, and other events that are useful for audit trails but do not require any response.
Alarm Routing and Escalation
Routing answers the question: who gets notified, through what channel, and when?
Routing should be role-based, not name-based. Instead of routing critical alarms to "John Smith," route them to the "on-call HVAC technician" role, and maintain a schedule of who holds that role each week. When personnel change, you update the schedule, not every alarm's routing configuration.
Escalation adds a time dimension. If a critical alarm has not been acknowledged within 15 minutes, escalate to a supervisor. If it has not been acknowledged within 30 minutes, escalate further. This prevents alarms from falling through the cracks when the primary responder is unavailable.
Using Alarm Analytics to Find Chronic Problems
Modern BAS platforms like Niagara N4 allow you to run analytics on your alarm history. This data is valuable for identifying chronic issues that are generating disproportionate alarm volume.
Sort your alarm history by source and count. You will almost certainly find that a small number of points generate a large percentage of your total alarms. This is your target list. For each chronic offender:
- Bad or intermittent sensor: Schedule replacement or rewiring.
- Equipment with a recurring fault: Schedule a service call to investigate the underlying condition.
- Setpoint that is fundamentally wrong: Adjust to a more appropriate threshold.
- Process issue: Maybe a specific operating condition always triggers this alarm, and the solution is to suppress it under those conditions or change the sequence.
The goal of alarm management is simple to state even if it requires real work to achieve: when an alarm fires, your operations team trusts it, knows what it means, knows how to respond, and acts on it. A system that achieves this is worth its installation cost many times over. A system that does not is background noise.