Why Nobody Reads Your Alarms

Walk up to almost any building automation front end and look at the alarm count. If it's in the hundreds or thousands, you already know what happened: alarms were enabled by default on everything, nobody rationalised them, and the operators quite reasonably stopped looking.

This is not an operator discipline problem. It is a design problem. An alarm system that produces more alerts than a human can act on has failed at its only job, and the failure mode is dangerous — because the one alarm that genuinely mattered arrives in the middle of the noise and gets silenced along with everything else.

The benchmark worth quoting. Industry guidance on alarm management holds that only a small fraction of alarms — on the order of five percent — should carry critical priority, and that sustained alarm rates during normal operation should stay low enough for one person to actually respond to each one. Most BAS installations are nowhere near either figure.

Why BAS alarm systems end up this way

Alarms are a default feature. Points arrive with alarming available, and enabling it is easier than deciding whether it's warranted.
Templates copy alarms. The same duplication that spreads a configuration error across two hundred boxes also spreads two hundred alarms.
Nobody owns the alarm list. It is nobody's job to prune, so it only ever grows.
Everything is the same priority. When a panel door switch and a freezestat carry equal weight, priority conveys no information at all.

The four fixes that do most of the work

Deadbands stop chattering

A value oscillating around an alarm threshold generates an alarm every time it crosses. Set the clear point meaningfully away from the trip point — if it alarms at 180, clear it at 175, not 179.9. Without a deadband, one condition produces dozens of events in minutes and buries everything else.

Delays filter transients

A brief spike during a normal start sequence is not an abnormal condition. An on-delay means the condition must persist before it alarms; an off-delay means it must clear before the alarm resets. Most start-up and changeover noise disappears with a sensible on-delay.

State-based suppression

An alarm that is valid in one operating mode is meaningless in another. Low flow during a planned shutdown is expected. Low discharge temperature on a unit that is off is expected. Tying alarm enablement to equipment state eliminates entire categories of nuisance alarm rather than trimming them one at a time.

Flood suppression and grouping

When one root cause produces twenty downstream alarms — a power supply failing takes a whole panel with it — the operator needs the root cause, not twenty symptoms. Group consequential alarms under the first-in fault so the display shows what actually happened.

Priority that means something

Priority is only useful if it is scarce. A three-tier scheme is enough for most buildings:

Tier	Means	Example
Critical	Act now. Risk to people, property, or a process that cannot wait.	Freezestat trip, fire system interface, critical space out of range
High	Act today. Equipment down or a comfort failure occupants will notice.	Air handler failed to start, chiller lockout
Maintenance	Log it, schedule it. Something is degrading but nothing is failing yet.	Filter differential pressure, runtime hours exceeded

Anything that doesn't fit those three probably shouldn't be an alarm. It can be a trend, a report, or a point on a graphic — all of which convey information without demanding a response.

How to actually run a rationalisation pass

Pull the alarm history for the last thirty days and sort by frequency. The top ten alarms are almost always most of your volume.
For each one, ask a single question: when this alarm fires, does anybody do anything? If the honest answer is no, it should not be an alarm.
Fix the top offenders first. Deadband, delay, or suppression — usually one of the three resolves it.
Then re-tier what's left using the three-tier scheme above.
Document what you disabled and why. This matters. An alarm silently turned off looks identical to an alarm that was never configured, and the next technician has no way to tell the difference.

Do not disable an alarm you don't understand. There is a real difference between an alarm that is noisy and an alarm that is noisy because something is genuinely wrong and has been for months. Before suppressing anything, confirm the underlying condition is actually benign. Silencing a real fault is worse than the noise it was making.

The connection to everything else

An alarm is the system's attempt to tell you that reality has diverged from expectation. When the alarm list is unreadable, you have lost that channel entirely — and you are back to discovering faults by complaint, which is the slowest and most expensive way to find anything.

Rationalising alarms is not administrative cleanup. It is restoring the system's ability to tell you the truth.

Go deeper

The method behind this, chapter by chapter

Every sensor, drive and control loop in the building — how it works, how to prove it with a meter, and how it fails. BAS Field Fundamentals is the method this article uses, with 20 field cases and a browser diagnostic simulator to practice on.

Get BAS Field Fundamentals

Found a wrong number or a broken link? Tell me and I’ll fix it.