There is a hard ceiling on how many alarms one operator can process per hour
Aliases: finite alarm-handling capacity · alarm rate
What it is
Alarm-handling capacity is finite because every alarm has to be oriented to, interpreted, weighed against other work, decided on, acted on, and logged — together these steps make up the alarm's "service time" for whoever is on console. When the arrival rate of alarms in a given window exceeds the rate at which they can be serviced, the unserved alarms accumulate in a backlog. That ceiling is what people mean by alarm-rate capacity, and it is set jointly by the task and the organization, not by a number that holds independent of the process, the interface, or the staffing on shift.
Why it happens
As arrival rate approaches service rate, queueing delay does not grow proportionally — it grows non-linearly. Think of utilization as the ratio of arrival rate to service rate: the closer that ratio gets to one, the faster expected wait time climbs, and the more sensitive it becomes to small increases in arrival rate. This explains a counterintuitive pattern: a daily average alarm count that looks perfectly normal can still coincide with a spike period that spirals out of control, because it is peak utilization — not the average that smooths the spike away — that determines whether the queue diverges.
Service time itself is not constant either. Ambiguous alarm text, root causes that require navigating several display layers to confirm, or competing concurrent tasks all lengthen the service time for a single alarm, which is equivalent to lowering the service rate, so the same arrival rate crosses the capacity ceiling more easily. A quick acknowledgement is not completed service: pressing acknowledge only removes the alarm from the pending list, it says nothing about whether diagnosis or a control action has actually happened, a distinction that an "average acknowledgement time" metric routinely hides.
Studying it
The standard way to size alarm-handling capacity is human-in-the-loop control-room simulation: using a full-scope or part-task training simulator, systematically vary the alarm arrival rate or its rhythm (steady versus bursty), have operators run ordinary monitoring and response tasks, and record their behavior and subjective load. Simulation is used precisely because a real plant cannot be made to pile up alarms just to run an experiment.
Typical independent variables are arrival rate, whether arrivals cluster, the number of concurrent tasks, and how ambiguous the alarm text is; typical dependent variables are time to first acknowledgement, time to first effective control action, the backlog-length curve over time, and subjective workload scores. The purpose of this work is to calibrate the arrival rate at which backlog keeps growing instead of settling, so a specific plant can set its own target rate rather than borrow an industry-wide figure.
One methodological caution: simulator scenarios are usually scripted, finite-duration event sequences, while a real shift is continuous and open-ended, so short sessions tend to underestimate how backlog accumulates over a long watch. Real alarms also arrive with strong temporal correlation — a single root cause trips several instruments within seconds — and correlated arrivals overwhelm a queue faster than independent ones would, yet a tidily designed experiment can inadvertently condition this correlation away unless clustered-arrival conditions are built in on purpose.
Where it stops holding
Capacity shifts with team size, operator expertise, automation, alarm type, and the phase of the incident; an hourly average conceals short bursts and says nothing about which alarms are competing for the same person's attention. A frequently cited steady-state benchmark from EEMUA 191 puts a manageable long-term average around one alarm per ten minutes (roughly six per hour); rates well above that fall into an over-demanding range — but that benchmark describes steady-state operation. Short-term arrival rates during an upset can legitimately run far above it, so the steady-state figure is the wrong yardstick for judging performance during a burst.
This entry is about the queueing capacity itself — whether alarms get picked up in time. What order they should be processed in, and which ones get overlooked in a backlog, are separate questions.
Applying it
Compute inter-arrival time, first assessment time, first effective action time, and backlog length from alarm and operator logs, broken down by role and by incident phase — the same arrival rate implies a different capacity for a single operator than for a team that splits the work.
Replay real historical peak periods, not a design assumption, and check whether the backlog returns to zero within a reasonable time after the peak rather than settling at some persistent non-zero level. A non-zero floor signals a genuine capacity shortfall that needs fewer alarms, more staff, or more automation — tweaking the acknowledgement workflow will not fix it.
How to check: extract, from the logs, the time from each alarm's trigger to the first effective control action, bin these by arrival-rate range, and plot arrival rate against average wait time. The rate at which the curve turns sharply upward is the system's actual capacity ceiling — use that number in place of any unverified industry figure.