What matters for a real incident is whether the alarm channel holds up during its busiest minute

What it is

Peak alarm load measures the number of arrivals and the backlog that builds up during the single busiest short window, used to judge whether the alarm channel remains usable when an actual incident disturbs the process. This leaf is only about how this one statistical dimension — the peak window — should be defined and used; how to read the long-term average, which alarms count as bad actors, and how often the metric should be reviewed belong to the other three leaves in this group. The window length must be relevant to the actual response task and stated explicitly whenever the number is reported, not buried in a methodology footnote.

Why it happens

A low overall average and an extreme burst lasting only a few minutes are not contradictory — the average is, by construction, what remains after peaks and troughs are flattened together. Peak analysis exposes several problems at once: whether the display itself can carry that many simultaneous alarms, whether queuing and presentation order make sense, whether several roles end up in conflict over the same batch of alarms, and where the team's actual service capacity ceiling lies. But counting arrivals alone is not enough — whether critical alarms received a fast enough first response, and how long the backlog actually took to clear, are both invisible in a single arrival number.

Where it stops holding

A historical peak is not an upper bound on the worst credible incident — a real event can exceed anything on record. Restoring communications after an outage often releases a batch of buffered messages all at once, and the resulting peak reflects the behavior of the recovery process rather than the process's genuine alarm load. Peaks computed over different window lengths are not comparable to each other, and a window length must never be chosen after the fact simply because it produces a more favorable number.

Applying it

Predefine several task-relevant windows — for example the first few minutes after an incident begins, and a longer sustained-treatment phase — and report arrivals, unacknowledged backlog, first response time for critical alarms, and time to recover to normal for each. Stress-test using both replays of real historical incidents and more severe, hazard-analysis-derived but still credible scenarios; do not treat the worst thing that has actually happened as the ceiling for testing.

Related

• Same group: Y2.08.1 Average alarms per hour · Y2.08.3 Bad-actor alarm concentration · Y2.08.4 Alarm-performance drift
• Nearby: Y2.02 Alarm floods and workload limits · Y1.06 Detecting and highlighting anomalies
• Search terms: peak alarm load · alarm flood · alarm management performance metrics