How many alarms arrive per hour on average is one of the most basic health checks for the system
Aliases: average alarms per hour · average alarm rate · EEMUA 191
What it is
Average alarms per hour summarizes the overall load reaching an operator over an observation period, and it is one of the most basic health indicators for an alarm system — industry guidance such as EEMUA 191 treats it as a starting point for assessment. It is well suited to viewing long-term trends and comparing load across operating states or units, but this leaf is only about what this one statistic — the average — can and cannot tell you; peak windows, bad-actor identification, and how often the metric should be reviewed belong to the other three leaves in this group.
Why it happens
Compressing a large number of discrete alarm events into a single average rate makes it easy to compare across periods or units, and easy to spot an overall load drift after commissioning or a change. But that compression also flattens away detail: a short burst of concentrated alarms, unusually dense night-shift activity, or one role carrying far more load than others can all be quietly diluted by the average, making things look fine "on average" when they are not. Using acknowledgement counts as a stand-in for actual arrivals also systematically distorts load, since a single arrival can be split into several acknowledgement actions, or a batch of arrivals can be cleared with one bulk acknowledgement.
Where it stops holding
Different standards and organizations may publish their own target ranges, but those ranges were derived under a specific counting convention, a specific scope, and a specific operating state, and cannot simply be transplanted as a pass threshold onto a completely different setting. Shutdown periods, extended maintenance windows, and stretches where the logging system itself has gaps all distort the denominator; unless these periods are excluded or flagged separately, the resulting average represents neither normal nor abnormal operation cleanly — it becomes a mixed number with no clear meaning.
Applying it
Report the mean alongside the median, several percentiles, peak windows, the current operating mode, priority distribution, and the load carried by each role, rather than a single blanket average, and fix the deduplication and counting convention in advance rather than changing methods midstream. Periodically sample raw logs to verify that the statistics pipeline is computing correctly, and when a trend shows an unusual swing, drill down to the specific alarms driving it rather than stopping at speculation about the aggregate number.
Related
Cards in the same group
- Y2.08.2What matters for a real incident is whether the alarm channel holds up during its busiest minute
- Y2.08.3A handful of chattering tags generating most of the alarm volume are the ones worth fixing first
- Y2.08.4As the process itself changes over time, alarm rates and response times quietly drift out of spec