Acknowledged Isn't Cleared: How to Run a Standing Alarm Review
Standing alarms are acknowledged but still active. Reviewing them against the ISA-18.2 stale-alarm metric before they become summary wallpaper.
Acknowledged isn't cleared
Open the alarm summary on any plant that's been running a few years and count the alarms that have been active since before the current shift started. On a big continuous unit it's rarely fewer than twenty. Every one of them has been acknowledged, so the horn is quiet and the banner is calm — and every one of them is an abnormal condition that nobody is currently doing anything about.
ISA-18.2 (adopted as IEC 62682) has a name for this: a stale alarm is one that stays active for more than 24 hours. The standard's benchmark is fewer than 5 stale alarms present on any given day, averaged. Most sites I've walked into are running ten to fifty. The gap between those numbers is the whole problem, and closing it is what a standing alarm review is for.
An acknowledgement means exactly one thing: a human saw the alarm and silenced the horn. It says nothing about whether the condition cleared, whether the risk was accepted, or whether a work order exists. If nobody ever revisits the acknowledged-but-active pile, the alarm system quietly loses the operators' trust, and the day a real upset lands in the middle of that noise, it gets acknowledged along with everything else.
This is a duration problem, not a rate problem
Don't run the standing alarm review out of your flood analysis. They measure different failures. Flood analysis lives in the ISA-18.2 rate metrics — alarms per 10 minutes, the target of ≤1 per 10 min in steady state, the flood threshold of >10 in 10 min. It's about bursts.
Standing alarm review is about the other axis: time active. A tag that fires once and stays up for three weeks contributes almost nothing to your flood numbers and is one of the most damaging things on the system. The two reports don't overlap, so build the standing one separately, sorted by active-since timestamp — not by last acknowledgement, which resets every shift and hides true duration.
The minimum columns that make the review actually work:
| Field | Why it earns a column |
|---|---|
| Active since (not last ack) | True duration — this is the sort key |
| Priority | Sets review cadence and escalation |
| Suppressed / shelved / disabled | Catches long-term bypasses hiding off the main list |
| Operator note / work-order ref | Ties the alarm to real work, or exposes that there is none |
| Expected clearance condition | Defines what "done" even means for this tag |
If your system can only give you the live banner, you can't do this review — the banner is built for the next thirty seconds, not the last three weeks. Get a historian-backed report or an alarm-analysis view first.
What to look at daily, and what can wait a week
A cabinet-fan low-flow alarm during a planned shutdown and a high-priority safety permissive left active on a running line are both "standing," and treating them the same is how the review dies of tedium. Look at these every shift or every morning meeting:
- High and critical alarms active longer than their allowed response time.
- Anything tied to safety, environmental, quality, or regulatory consequence.
- Comms and data-quality alarms — a bad-quality flag on a key measurement means you're flying blind on that value.
- Suppressed, shelved, or bypassed alarms approaching their expiry. A shelve with no timeout is a design defect; ISA-18.2 expects shelving to auto-unshelve.
- Alarms that crossed shift handover with no named owner.
- Alarms that go standing again on the same equipment after a maintenance sign-off — that's a repair that didn't take.
Low-priority alarms can move to a weekly pass, but they don't get to vanish. An old low-priority standing alarm is usually a symptom: a drifting instrument, nuisance logic that should have been rationalized out, or a maintenance loop that never closed.
Give the operator the context on one screen
If understanding a single standing alarm means opening the historian, the CMMS, and the PLC program, the review won't survive contact with a busy shift. Put enough on the alarm detail view — or the standing report row — to decide the next action without leaving it:
For Cooling Water Low Pressure, that's the current pressure and the low limit side by side, the pump-running feedback, the instrument quality bit, and whether a work order already exists. Now the operator can tell in five seconds whether it's a real low-pressure event, a dead transmitter reading zero, or a known fault already in maintenance's queue. Without that, "why is this still here?" costs a phone call every shift, so it stops getting asked.
The failure modes that keep it broken
Acknowledge becomes the ignore button. Same alarm, every shift, immediate ack, move on. That's the alarm telling you it isn't actionable, or its owner is undefined. Either attach an expected action or reclassify it — an event log entry, not an alarm.
Disabled and suppressed alarms fall off the list. Plenty of systems drop out-of-service alarms from the normal view, which is exactly how a six-month bypass becomes invisible. The standing report has to carry disabled, suppressed, shelved, and out-of-service states in their own section, with the age of the bypass shown.
Chattering alarms clear right before the meeting. If the report only shows currently-active tags, a point that flips active/clear forty times a day escapes — it's never "standing" at the moment you look. Include total active time and activation count over the last day and week, not just the instantaneous state.
Nobody knows the clearance condition. Does it self-clear? Need a reset? Wait on a PLC bit? Require a maintenance closeout? When that's undocumented, the alarm sits active by default. One sentence in the alarm documentation fixes it permanently.
Priority is used as a junk drawer. Annoying and low-risk are not the same thing, but annoying alarms keep getting demoted to low priority so they stop nagging. Audit the old low-priority pile by age. If a tag needs no operator action, it isn't an alarm.
Hand it over out loud
Standing alarms break at shift change more than anywhere else. The outgoing operator carries the whole story in their head; the incoming one inherits a list of already-acknowledged rows with no narrative. The handover doesn't need a meeting, it needs a habit: name every high-priority standing alarm, call out anything that's disabled a measurement or control function, state whether it's accepted for the next shift or needs action tonight, and confirm who owns it — operations, maintenance, controls, process, or vendor. If the reason or owner changed during the shift, the note gets updated before you leave.
Track the two numbers that drive cleanup
Metrics here exist to push work orders, not to fill a dashboard. Two are enough to start: count of stale alarms (active >24 h) by priority and area, and oldest active alarm by priority. Add total active duration by equipment over the last week when you want to find the worst repeat offenders. Watch the stale count against the ISA-18.2 target of under 5 — if it never moves, your review isn't wired to real maintenance work or to alarm rationalization, and no amount of prettier charting will change that.
Close with a reason, not just a reset
When a long-stander finally clears, write down why: instrument repaired, setpoint corrected, equipment back in service, logic changed, or removed in rationalization. Next month, when the same tag reappears, that one line is the difference between diagnosing it fresh and knowing it's the third time this transmitter has drifted. Keep it to symptom, cause or accepted reason, change made, verification, and date/owner — five short fields.
That closing note is why the review is worth running at all. It's not an operations chore; it's the feedback path back to HMI design, PLC logic, instrumentation, and the alarm philosophy document. Cut it and you're just resetting alarms. Keep it and the summary is still readable the next time something actually goes wrong.