An operator can only absorb, understand, and act on so many alarms before the system stops helping and starts overwhelming. The industry answer to how many is too many is expressed as an acceptable alarm rate, a small set of benchmark numbers that describe an alarm load a human can genuinely keep up with. This guide explains what those benchmark rates are, why the human limits behind them are so modest, and how a site measures its own performance against them.
Acceptable alarm rate in one line: An acceptable alarm rate per operator is a benchmark for how many alarms one person can handle and still respond properly, drawn from widely used guidance such as EEMUA 191 and the ISA-18.2 approach. The commonly cited targets are on the order of one to two standing alarms at any time, a manageable average of only a handful of alarms per hour, and very few ten-minute periods with a burst above ten alarms. Above these levels an operator falls behind, misses important events, and the alarm system stops protecting the process.
Acceptable alarm rate is not one number but a small family of measures, because an operator's load has several dimensions. One is the average rate over time, typically expressed in alarms per hour, which captures the steady background workload during normal operation. Widely used guidance points to an average that is low enough for an operator to read and act on each alarm rather than simply clearing them to make the noise stop. When the hourly average climbs well above this, alarms start being acknowledged reflexively and their information value collapses.
A second measure is the count of standing alarms, meaning alarms that are active and remaining active at any given moment. The target here is very small, on the order of only one or two, because standing alarms clutter the display and mask new events. If an operator's screen is permanently full of alarms that are always on, a genuinely new and important alarm has nowhere to stand out. A third measure is the peak rate, usually assessed over short windows such as ten minutes, which describes how the system behaves during upsets rather than during calm.
Together these measures paint a picture of whether the alarm system is sized to the human watching it. A site can look fine on the average and still be dangerous during peaks, or look calm on peaks while carrying a permanent backlog of standing alarms. This is why acceptable alarm rate is always discussed as several numbers at once, each describing a different way an operator can be overloaded, rather than a single headline figure.
The reason the acceptable rates are modest is not caution for its own sake; it reflects what a person can actually do with an alarm. Responding to an alarm properly is not a click. It means noticing it, reading it, understanding what it means for the process, deciding what to do, taking that action, and confirming the result, all while continuing to run the rest of the plant. Each of these steps takes real time and attention, and there is a limit to how many such cycles a person can complete in an hour without cutting corners.
When alarms arrive faster than they can be worked through this way, the operator adapts in the only way available: by triaging less carefully, acknowledging faster, and effectively ignoring lower-priority alarms to stay afloat. The alarm system is then technically still running, but it has stopped functioning as a safeguard, because the operator is no longer processing what it tells them. The acceptable-rate benchmarks are set below that breaking point specifically so the operator retains the headroom to think about each alarm rather than merely dismiss it.
Peaks matter even more than averages here, because upsets are precisely when the alarm system is supposed to earn its keep. A plant disturbance can generate a burst of alarms in seconds, and if that burst pushes the operator far past the manageable rate at the very moment a critical decision is needed, the flood can hide the one alarm that mattered. The low peak target exists to ensure that even during an event, the operator is presented with an intelligible number of alarms rather than an unreadable wall of them.
To know whether a site meets the benchmarks, the alarm system's own event history has to be analysed. Every alarm activation carries a timestamp, so it is straightforward in principle to count alarms per hour, to identify how many were standing at any instant, and to find the busiest ten-minute windows. The practical difficulty in traditional systems is that this history is often trapped in a local logger, hard to extract, and never turned into the simple time-based rates that the benchmarks call for. A site can be badly overloaded without anyone ever computing the number that would prove it.
A cloud SCADA platform such as Merobix changes this because the alarm stream from every well, pad, and facility is already timestamped and centralised, which is exactly the raw material these rates require. The same records that drive live notifications can be aggregated after the fact into average alarm rate per operator, into counts of standing alarms, and into peak rates over short windows, so a site can be measured against the acceptable benchmarks without a special data-gathering project. When operations span many remote sites, this fleet-wide view also reveals which sites are quietly generating the bulk of the load.
Measuring the rate is only useful because it points to action. If the average is too high, the usual cause is a population of nuisance and chattering alarms that should be rationalized or corrected. If standing alarms are too many, some alarms are misconfigured to stay active when they should clear. If peaks are the problem, the fix often lies in flood suppression or state-based alarming to tame the bursts that accompany known transitions. In each case the acceptable-rate benchmarks turn a vague sense of too many alarms into a concrete, trackable target for improvement.
Widely used guidance points to an average of only a handful of alarms per hour as manageable, because responding to each alarm properly takes real time and attention. Well above that, operators start acknowledging alarms reflexively rather than acting on them. The exact acceptable figure depends on the process, but the target is deliberately low so operators keep the headroom to think about each alarm.
A standing alarm is one that is active and remaining active at a given moment rather than clearing. Guidance calls for very few of them, on the order of one or two at any time, because standing alarms fill the display and hide new events. A screen permanently full of always-on alarms leaves no room for a genuinely new and important alarm to stand out.
Peaks happen during upsets, which is exactly when the alarm system is supposed to help most. A process disturbance can produce a burst of alarms in seconds, and if that burst pushes the operator far past the manageable rate, the flood can bury the one alarm that mattered. The low peak target, usually measured over short windows, exists so operators still get an intelligible number of alarms even during an event.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.