Designing Alarm Severity and Escalation for Facilities

Open the alarm list on a typical building management system and you will find several hundred active entries, most of them months old, all of them nominally requiring attention. The operator has long since learned to read past them. When something genuinely important happens it appears in the same list, in the same colour, in the same font, between a filter that has been dirty since spring and a sensor that was decommissioned in a refurbishment. The system is working exactly as configured. That is the problem.

The message up front: severity is a statement about consequence and required response time, not about how serious the equipment sounds. Build a small scheme, three or four levels at most, define each level by what it obliges somebody to do and how quickly, then assign every alarm in the estate to a level in a structured review rather than by instinct. Escalation chains off severity automatically. Keep the scheme small, keep the top level genuinely rare, and treat any level with hundreds of members as evidence the scheme is wrong rather than the building is broken.

1. Why default severity is worthless

Controls systems ship with a severity or priority field and almost always with a default value, and the default is what most points keep for life. Three things follow.

• Severity ends up describing the alarm's source, not its consequence. A fault contact is treated as more serious than a temperature excursion because it is binary and sounds definitive, even where the excursion affects occupants and the fault does not.
• The scheme has too many levels. Systems commonly offer wide numeric ranges, and given a wide range people use it, producing fine gradations nobody can distinguish in practice and nobody acts on differently. If two levels do not produce different behaviour, they are one level.
• Nothing forces a review. Severity is set once per point during engineering, by whoever was configuring that controller, under programme pressure, usually by copying the previous project. Nobody revisits it, because nothing in the handover process asks.

The result is an alarm list that is technically complete and operationally inert. This is an alarm management failure rather than a controls failure, and the wider context sits with the handover disciplines in BMS commissioning, graphics and operator dashboards.

2. Severity is about consequence and time

The single most useful reframing is to stop asking "how bad is this fault" and start asking two narrower questions: what happens if nobody does anything, and how long do we have before that matters.

Those two questions make severity assignable by people who are not controls engineers, which matters because the people who understand the consequence are facilities managers, operations staff and the business occupying the building, not the person who wrote the control logic. They also make severity defensible: an assignment you can justify by naming the consequence survives a challenge, and one based on how important the equipment feels does not.

A worked illustration of how differently the two framings land. A chilled water pump fault on a duty-standby pair where the standby starts automatically has a real fault contact and almost no immediate consequence, because the building keeps running; it needs attention within days to restore redundancy. A gradual space temperature drift in a space holding temperature-sensitive stock has no fault contact at all and a serious consequence within hours. Severity based on the sensor ranks these the wrong way round. Severity based on consequence does not.

3. A severity scheme that works

Four levels is usually right. Three can work. More than four produces distinctions people cannot apply consistently.

Two design rules keep the scheme honest. First, each level must oblige different behaviour; if critical and urgent produce the same action at the same speed, you have three levels, not four. Second, the informational level must be genuinely separated in the interface rather than merely labelled, because an operator view that mixes logged status with actionable conditions is the thing you are trying to fix.

4. Severity, priority and urgency are three things

These get used interchangeably and then collide at the boundary between the building system and the maintenance system.

• Severity is a property of the condition: how bad the consequence is. It is set at design time, per alarm, and rarely changes.
• Urgency is a property of the moment: how soon it matters given current circumstances. The same alarm is more urgent in an occupied building on a hot afternoon than at two in the morning in an empty one.
• Priority is the scheduling decision that comes out of combining them with everything else in the queue: criticality of the asset, resources available, other open work. It belongs to the maintenance system and it changes constantly.

The practical consequence is that the building system should send severity and let the maintenance system derive priority, rather than trying to send a priority directly. Severity plus asset criticality plus time of day gives the maintenance system what it needs to decide, and the asset side of that input is the classification described in asset criticality classification. Where the same physical condition on a critical asset and a spare one arrives at identical priority, this separation is what is missing. The resulting work order classification then follows the scheme in CMMS work order types.

5. The escalation chain

Escalation exists for one reason: to cover the case where the first recipient does not respond. Everything else about it follows from that.

• Escalate on unacknowledged, not on unresolved. Acknowledgement means a human has seen it and owns it. Resolution can take days legitimately. Escalating on resolution time produces constant noise and trains people to ignore the escalation itself.
• Define the chain by role, never by person. Named individuals leave, go on holiday and change teams, and an escalation chain pointing at a departed employee is a silent single point of failure. Roles resolve to people through a rota that somebody maintains.
• Make each step wider, not just higher. Step one is the duty technician, step two is the supervisor plus the technician, step three adds the manager. Replacing the recipient rather than adding to the group loses the person who may already be working on it.
• Give the chain an end. A final recipient who is always reachable, and an explicit statement of what happens if even they do not respond. Chains that loop back to the start quietly stop meaning anything.
• Acknowledge once, in one place. If acknowledgement is possible in both the building system and the maintenance system, the two states will diverge, and the question of which one counts is the subject of the alert-to-work-order audit trail. Pick one as authoritative before go-live.
• Log every step. Who was notified, by what channel, when, and whether they responded. Without this the chain cannot be reviewed, and an unreviewed escalation chain degrades within a year.

Response-time commitments to contractors or internal customers are a separate matter from the technical chain, and conflating the two produces a chain designed around a contract rather than around the building. Where the obligations are contractual, the structure belongs with the approach in SLA matrix design for FM operations.

6. Out of hours, which is where schemes fail

A severity scheme that works in office hours and floods somebody's phone overnight will be switched off within a fortnight, and when it is switched off it will be switched off entirely rather than selectively.

• Only the top level notifies out of hours. Everything else queues for the morning. If that feels too restrictive, the top level is populated wrongly rather than the rule being wrong.
• Severity can be time-dependent, and should be. A comfort condition in an occupied space is urgent at ten in the morning and routine at ten at night. Making occupancy or schedule an input to notification rather than to severity itself keeps the scheme stable while the behaviour varies.
• Batch the overnight queue into one morning summary, rather than delivering sixty individual notifications at seven in the morning.
• Protect the rota. One person receiving critical alarms every night for a month will stop reading them. Rotation is an alarm management control, not just an HR arrangement.

7. Assigning severity across an existing estate

Designing the scheme takes an afternoon. Applying it to several thousand existing alarms is the actual work, and doing it point by point in the controls interface is how the exercise dies.

What works better is a structured review, sometimes called alarm rationalisation, run as a short series of workshops against a spreadsheet rather than against the live system:

• Start from the alarm population, not the points list. Export every configured alarm with its point identity, its asset and its activation count over the last year. Count is the key column.
• Deal with the top of the count distribution first. A small number of alarms generate most of the volume. Several will turn out to be defective instruments or decommissioned plant, and deleting those is the fastest improvement available.
• Rationalise by alarm type across assets, not asset by asset. Decide once what a filter differential alarm means, then apply it to every unit. Going asset by asset produces inconsistency and takes many times longer.
• Record the justification. One line per alarm type stating the consequence that drove the level. This is what makes the scheme survive the next person, and it is the deliverable people skip.
• Include the operators. They know which alarms they already ignore, which is the most valuable single input and the one most often not asked for.
• Agree deletion explicitly. Alarms on removed plant, duplicated alarms and alarms nobody can name a consequence for should be removed rather than demoted. Demotion keeps them in the database forever.

Where the alarm configuration is only changeable by the controls contractor, this becomes a scoped piece of work to commission, and the terms it falls under are worth checking against your BMS service contract before assuming it is included.

8. The alarms that do not belong in this scheme at all

Some alarms are not maintenance alarms and must not be absorbed into a maintenance severity scheme.

Fire detection and alarm, life-safety functions, and anything with a statutory monitoring or reporting duty operate under their own regime, on their own systems, with their own response obligations defined by the standards and regulations adopted in your jurisdiction and by the authority having jurisdiction over your building. A building management system may display or receive status from these, and the boundaries for that are discussed in BMS integration with fire, access control and CCTV, but reclassifying, delaying, suppressing or routing such an alarm through a maintenance escalation chain is not a decision for a facilities alarm review.

The practical rule I would apply: identify these alarms first, mark them as out of scope before the rationalisation begins, and have the boundary confirmed by whoever holds responsibility for those systems. Put the question in writing. A severity review that quietly swept a life-safety signal into a routine queue would be a serious failure, and the way it happens is not malice but an export that did not distinguish the sources.

9. Measuring whether the scheme is working

Review these quarterly for the first year. Alarm populations drift as plant is added, replaced and reconfigured, and a scheme that is not reviewed returns to its default state within a couple of years. The review belongs alongside the other periodic obligations in BMS maintenance, servicing and lifecycle.

The idea to walk away with

A severity scheme is not a labelling exercise, it is a decision about where human attention goes. That makes it one of the few pieces of configuration in a building that directly determines whether the system is useful, and it is almost always left at its defaults.

Keep it small. Define every level by the consequence of inaction and the time available, not by the equipment. Let the maintenance system derive priority rather than receiving it. Escalate on acknowledgement, to roles rather than people, widening at each step. And treat the top level as a scarce resource: every alarm you add to it devalues the ones already there.

Final thoughts

The quickest way to find out where you stand is to export the active alarm list and count it, then count how many have been active for more than thirty days. In most buildings the second number is a large fraction of the first, and that ratio is the whole diagnosis: an alarm that has been standing for a month is not telling anybody anything, it is furniture.

Clearing that backlog, by fixing some and deleting others, is usually more valuable than any new monitoring investment, and it costs nothing but a structured afternoon and the authority to remove alarms that no longer mean anything.

Related reading: Alert deduplication between BMS and CMMS, Alert suppression during planned shutdowns, The alert-to-work-order audit trail, Asset criticality classification, SLA matrix design for FM operations, BMS commissioning and graphics.