In most process plants, a handful of tags produce the majority of the alarm load. Finding and fixing them is the single highest-return activity in alarm management — it needs no philosophy document, no workshop, and it typically removes 40–60% of total alarm volume. This article covers how to identify bad actors and what actually fixes each type.

The Concentration Rule

Alarm load is not evenly distributed. When you rank tags by alarm occurrence over 30 days, the curve is steep: it is common to find the top 10 tags producing 40–60% of all alarms, and the top 20 producing two thirds. Occasionally a single failed transmitter accounts for a fifth of a plant’s entire alarm count on its own.

This concentration is what makes the work tractable. You are not fixing ten thousand alarms. You are fixing twenty tags, and the flood baseline drops far enough that ordinary process upsets stop tipping into flood territory.

The Four Types Worth Naming

Type	Definition	Usual root cause
Chattering	Repeatedly activates and clears in a short period — three or more times per minute is the common test	Process variable sitting on the setpoint; no deadband; noisy signal
Fleeting	Activates and clears so quickly the operator cannot respond — typically under a few seconds	Signal spike, no on-delay, transient during switching
Stale	Remains active continuously for a long period — commonly defined as over 24 hours	Equipment out of service; alarm on a decommissioned item; setpoint permanently exceeded
Duplicate	Multiple alarms report the same physical condition	Same condition alarmed in DCS, PLC and package system independently

Each has a different fix. Treating them all as “nuisance alarms” and suppressing the lot is what creates the next incident.

How to Find Them

You need alarm and event history — 30 days minimum, 90 preferred so that turnarounds and upsets are represented. From the DCS historian or the alarm journal, extract at minimum: timestamp, tag, alarm type, priority, and the transition (activate / clear / acknowledge).

Then produce four rankings:

Occurrence count by tag — the raw bad-actor list.
Chatter ratio — activations per tag divided by distinct upset episodes. A tag that activates 400 times across 6 process events is chattering, not reporting.
Duration distribution — anything continuously active beyond 24 hours is stale by definition.
Time-to-clear distribution — a cluster under a few seconds identifies fleeting alarms.

Doing this once by hand in a spreadsheet is entirely feasible and worth doing, if only to see the shape of your own curve. Doing it continuously, so that new bad actors surface within days rather than at the next audit, is what needs tooling.

What Actually Fixes Each Type

Chattering — deadband first, delay second

The primary tool is deadband (hysteresis): the alarm clears at a value meaningfully different from where it activates. A common starting point is 1–5% of span for analogue measurements, wider for known-noisy services like flow on a slurry line.

Where deadband alone is insufficient — because the noise amplitude exceeds any sensible deadband — add an on-delay: the condition must persist for a defined time before the alarm is raised. A few seconds usually suffices for level and flow; use judgement on temperature and never on anything with a fast safety consequence.

The trap: on-delay directly consumes operator response time. If an alarm has a 30-second allowable response time and you set a 20-second delay, you have given the operator 10 seconds. Delay values belong in the master alarm database with the response time recorded beside them, not tuned quietly in the DCS.

Fleeting — usually a signal problem, not an alarm problem

A fleeting alarm generally means the measurement is spiking. The correct fix is upstream: check signal filtering, grounding, transmitter health and sample conditioning. Adding an on-delay to hide a spiking transmitter suppresses the symptom and leaves you blind to a genuine excursion later.

Stale — a process and record problem

Stale alarms are almost never a tuning issue. Typical causes and the corresponding action:

Equipment out of service → formal, time-bounded, recorded alarm shelving with an expiry and an owner
Decommissioned equipment → delete the alarm through management of change
Setpoint set at an unachievable value → re-rationalise the setpoint against actual operating envelope
Failed instrument left in service → a maintenance work order, not an alarm change

A standing alarm that nobody intends to clear is training operators to ignore the alarm banner. That habit does not switch off when a real alarm arrives.

Duplicate — decide which system owns the alarm

When the same physical condition is alarmed in a package PLC, the DCS and a third-party monitoring system, pick one owner — normally the one the operator actually watches — and demote the others to events. This is common on vendor skids and is best resolved at the design stage, which is why owner specifications increasingly require vendors to deliver rationalised alarm lists with their packages.

The Governance Part — Or It All Comes Back

Bad-actor cleanup has a well-known failure mode: a team spends six weeks removing 50% of the alarm load, the KPI chart looks excellent, and eighteen months later the rate is back where it started. Alarms accumulate the way technical debt does — one reasonable-seeming addition at a time.

What prevents the rebound:

A named owner for alarm system performance, with the KPIs in their objectives — not “the control team” collectively
Monthly bad-actor reporting, so a new chattering tag is caught in weeks rather than at the next audit
Management of change on alarms, including additions — a new alarm needs the same justification as an original one
An expiry on every shelved alarm, with automatic re-activation and escalation if it lapses

A Realistic First Month

Week	Activity	Expected outcome
1	Extract 30–90 days of history; build the four rankings	Ranked bad-actor list; baseline KPIs
2	Review top 20 tags with operations and instrument technicians	Root cause assigned per tag
3	Implement deadband/delay changes and raise maintenance work orders	Typically 30–50% load reduction
4	Clear stale alarms; formalise shelving with expiry; re-measure	Standing alarm count into single digits

This is before any rationalisation workshop. Rationalisation is the deeper and more valuable work, but it is slower and it benefits from being done on a system that is no longer drowning in noise.

Finding Your Own Bad Actors

Export 30 days of alarm history from your DCS or historian and we will return the ranked bad-actor list, the chatter and stale classifications, and an estimate of the load reduction available before any rationalisation is needed. NEO AEGIS does this continuously rather than as a one-off study.

Chattering Alarms and Bad Actors: The Fastest Win in Alarm Management