Tagging nearly every alarm high priority leaves the label carrying no information at all
Aliases: everything is critical · alarm priority creep
What it is
When nearly every alarm is tagged high priority, the classification stops carrying any ordering information — a failure mode called priority inflation. The labels are all still there, the sound, color, and queue position are unchanged, but once several alarms appear together the tag can no longer tell an operator what to handle first.
Why it happens
Priority only works as a relative, scarce signal — not every alarm can sit at the top, and putting one there means something else has to give way. But classification is usually a distributed decision: each equipment or system owner captures the benefit of raising their own alarm — louder, faster escalation, and cover if their equipment is later questioned — without bearing the cost of the resulting ordering confusion when several alarms fire together, a cost that lands on whoever is on shift facing the whole set. Owner and cost sit on different people, a textbook externality, and as long as classification authority stays distributed among owners acting independently, the direction is hard to reverse on its own. It only breaks once one party owns the whole plant's classification scheme and can decline or downgrade an individual request — at that point the cost and the decision are held by the same party.
Inflation can also arise without any distributed game at all, as a byproduct of a rushed rationalization exercise: facing a large alarm count and too little time to work out consequence and response time for each one individually, a team defaults the undecided items to high priority, meaning to split them out later, and never does. Here no owner is angling for attention, so the fix differs too — not installing a single gatekeeper to correct the incentive problem, but going back and finishing the item-by-item assessment that was skipped.
Studying it
Public investigation reports into major process-safety accidents have repeatedly named a flood of visually indistinguishable high-priority alarms as a contributing factor, which is the most direct evidence for this failure mode. A second approach analyzes the alarm log: comparing the share of alarms configured at the top tier against the order in which operators actually acknowledged alarms during a real flood. When the top tier is large but the acknowledgment order clearly tracks arrival time or operator habit rather than the assigned level, the tier has stopped guiding behavior.
Where it stops holding
A small, genuinely high-hazard unit can legitimately have most of its alarms at the top tier, so the proportion alone is not the test; what matters is whether, when several alarms arrive together, operators still have an executable first and second action and the capacity to carry them out. Independent protection functions that already act automatically should not share the same top tier as alarms needing a human response — an action the system already takes on its own does not need to compete for the operator's attention, and folding the two together only makes inflation harder to notice. A large batch of alarms jumping to the top tier together within seconds of an emergency shutdown is not inflation either — inflation describes a standing, static misconfiguration, not the brief, concentrated surge that a real trip legitimately produces, and the two should not be judged by the same yardstick.
Applying it
Instead of reviewing alarms one at a time, review them against concurrent scenarios: present combinations that have actually occurred together and ask the responsible team to name the first and second actions and the time basis for each. A group that cannot produce a distinguishable order usually means one of three things — a removable nuisance alarm is cluttering the set and the trigger logic needs fixing first, the underlying consequence or response-time estimate does not hold up and needs reassessment, or the concurrency is real and unavoidable, in which case staffing and response procedures should be sized to that real load instead of stacking more alarms at the top. Retest under a simulated flood afterward and check whether operators can still state a defensible order when that set of alarms arrives together. If different operators give contradictory orders on retest, the problem is not individual experience but a classification that fails to communicate a consistent basis for ordering — the fix is to return to the concurrent review, not to add more training.