What Is an Alarm Flood? Causes, EEMUA 191 and ISA-18.2 Benchmarks, and How to Stop Them

What Is an Alarm Flood?

An alarm flood is a burst of alarms that is too fast for an operator to handle well. ANSI/ISA-18.2 and IEC 62682 give more than 10 alarms in 10 minutes per operator as the alarm flood definition. EEMUA 191 adds an end point: the flood is over once a 10-minute period has fewer than five new alarms.

When you test for an alarm flood, only count new alarms on one console, and leave out alarms that clear, acknowledgements and plain event messages.

Comparison of the alarm flood detection limit with the target average alarm rate under steady-state conditions. 

These two numbers do different jobs, so it helps to keep them apart in your reports.

A console can stay below the alarm flood detection threshold all day and still be overloaded. Eight alarms every 10 minutes never triggers an alarm flood, but it is still eight times the steady-state target.

Why the definition matters

Picture a crude transfer pump that trips. Within minutes, the operator sees alarms for low pressure, low flow, a stopped motor, low flow at the next heater and a rising tank level. That can be 12 alarms in a few minutes, which is an alarm flood, yet only one of them is the real cause. A clear alarm flood definition lets your team count events like this and fix the alarms that make them worse.

Why Are Alarm Floods Dangerous?

During an alarm flood, the alarm system can end up hiding the very problem it is meant to show.

• Key alarms get buried. An urgent alarm can scroll out of sight while the operator deals with less important ones.
• Action is slower. Each alarm requires time to review, assess and acknowledge, meaning an excessive number of alarms can slow down responses to critical events. 
• Operators tire. Alarm fatigue occurs when operators are exposed to an overwhelming number of low-priority alerts, causing them to become less attentive and potentially miss critical warnings. 
• The first cause is hard to find. Dozens of linked alarms can hide the event that started the whole chain.
• Risk spreads. Slow or wrong action can affect process safety, production and equipment reliability.

An illustrative upset

Consider a hypothetical scenario on a gas platform: a compressor shuts down due to high vibration, causing pressure to build as upstream vessels begin to back up. In eight minutes the operator gets 40 alarms, and the trip alarm that explains them all sits near the bottom of the list. With good design, the trip alarm would stand out and the expected follow-on alarms would be grouped, so the list would be far shorter and clearer.

A documented case: BP-Husky Toledo Refinery (2022)

The US Chemical Safety Board (CSB) looked into a fatal fire at the BP-Husky Toledo Refinery in Ohio. Its final investigation report found that operators had faced an alarm flood for nearly 12 hours, with 3,712 alarms. The CSB found that the alarm flood overwhelmed and distracted the operators, which caused delays and errors in their response to critical alarms.

The CSB named the alarm flood as one of several safety issues rather than the only cause. It also asked ISA to add targets that help sites judge each single alarm flood event.

EEMUA 191, ISA-18.2 and IEC 62682 Compared

Three documents guide most ISA-18.2 alarm management work, and while they are closely linked, they are not the same.

EEMUA states that both standards are aligned with EEMUA 191. In short, EEMUA 191 gives practical targets, while ISA-18.2 and IEC 62682 set out the lifecycle that a well-run alarm system should follow.

What alarm frequency is considered manageable for an operator? 

During steady operation, about 1 alarm per 10 minutes per console is the target. This equates to roughly six manageable alarms per operator each hour, or around 150 over a 24-hour period. ISA-18.2’s metrics treat 2 alarms per 10 minutes (12 an hour, 300 a day) as the most an operator can manage. EEMUA 191 gives a similar steady-state target.

These figures apply to steady running and assume at least 30 days of data. After a major upset, the aim is no more than 10 alarms in the first 10 minutes. Track both the average and the peak, because a good average can hide a serious alarm flood.

Alarm flood benchmark table

Each figure below is labelled by type. A published benchmark comes from a named standard or guide. An investigation trigger is a practical level at which Sarom Global suggests a closer look, and it is not taken from any standard. Figures marked illustrative, used only in the dashboard example later, are made up to show a format.

Sources: ISA-18.2 metrics as reproduced in Improving alarm management with ISA-18.2 (2009 edition); EEMUA 191 targets as cited by the ASM Consortium. Check each figure against the edition your site uses.

Three points help when you read this table:

1. Published figures are a guide, not the law. Meeting them does not prove regulatory compliance or a safe plant.
2. Your site sets its own targets. Final figures belong in your alarm philosophy and may differ between plants and consoles.
3. Abnormal operation is different. Startup, shutdown and process upsets need their own targets, separate from steady running.

Five Common Causes of Alarm Floods

Most alarm floods have more than one cause, so use the list below as a checklist rather than a single answer.

1. Cascading process events

One trip, power dip or communications failure can set off a chain of related alarms and a full alarm flood. Check: alarms that always show up together after the same event, because they may suit first-out alarms, grouping or designed suppression.

2. Poor alarm rationalisation

Rationalisation is the review that confirms each alarm is needed and has a clear operator action. Without it, alarms pile up over years of projects and changes. Check: alarms in your master alarm database with no stated cause, consequence or operator response.

3. Chattering and fleeting alarms

Chattering alarms switch on and off again and again, often three or more times in a minute, while fleeting alarms clear before anyone can act. One faulty point can cause hundreds of alarms a day and trigger an alarm flood on its own. Check: noisy instruments, limits set too close to normal values, and missing deadband or delays.

4. Priority inflation

Too many alarms are set to high priority “just in case”, so priority no longer shows the operator what to do first. Check: your priority split, and each high-priority alarm against its consequence and response time.

5. Weak change control

New alarms, changed limits and temporary bypasses build up without proper review, and a well-designed system slowly drifts back into poor performance. Check: gaps between the live system and the master alarm database that have no approved change record.

How to Measure Alarm Flood Performance

Measure before you change anything. Pull at least 30 days of data from your alarm and event log, report each console on its own and use the same counting rules every time.

The main alarm management KPIs are average rate, peak rate, flood count, time in flood, standing alarms, chattering alarms, priority split, and shelved or suppressed alarms.

How to calculate alarms per operator per hour

Alarms per operator per hour = new alarms on one console ÷ hours in the period

How to count alarm floods the same way every time

Small changes in method can change your results, so write your rules down. Here is a simple method that gives repeatable alarm flood results:

1. Split time into fixed blocks. Use 10-minute blocks that start on the hour (10:00, 10:10, 10:20). Do not let blocks overlap.
2. Count only new alarms. Leave out returns to normal, acknowledgements, events and duplicate records.
3. Mark the start. A flood starts in the first block with more than 10 new alarms.
4. Mark the end. Following EEMUA 191, the flood ends at the first later block with fewer than five new alarms.
5. Record each flood event. Note its start, end, alarm count and peak block.
6. Work out time in flood. Add up the length of all flood events, then divide by total time.

Flood events show how often an alarm flood happens, while time in flood shows how much of each shift was spent in one, so report both. A sliding window will give higher peak counts, so never compare results from different methods.

How to find the alarms causing most of the load

Rank every alarm by how often it occurred. The top ones are often called “bad actors”, and in many plants a short list of them causes much of the load. Note which bad actors show up during each alarm flood, not just across the month. Our DCS alarm management practical guide for plant operators explains how these KPIs fit into a wider program.

What Should You Fix First?

When alarm floods keep coming back, do not start by changing limits across the whole system. Instead, start where the risk and the alarm load are greatest.

1. Study recent floods. For each one, identify the event that started it, the console it affected and the alarms that appeared together.
2. Judge the risk. Ask whether important alarms were hidden, or whether operators had too little time to respond safely.
3. Target the worst contributors. Put repeat chattering alarms, alarms with no operator action and poorly defined alarm responses at the top of the list.
4. Make controlled changes. Agree each change with operations and engineering, follow management of change and test every change before it goes live.
5. Verify the result. Compare alarm rates, flood count and time in flood with your baseline, and confirm that important alarms still work as intended.

Rank fixes by risk and by how much each alarm adds to the load, because how often an alarm occurs is only part of the picture.

How to Stop and Reduce Alarm Floods

Learning how to reduce alarm floods means running a steady improvement loop instead of a single clean-up project: measure, fix, check and repeat.

1. Measure the baseline

Use the counting method above to record rates, flood events, time in flood and bad actors for each console, and repeat it after every round of changes.

2. Rationalise alarms

Review each alarm with operators and engineers. Confirm why it exists, what the operator must do, how much time they have and what priority it needs. If no operator action is needed, turn the alarm into an event or log entry.

3. Fix chattering alarms at the source

Do not just hide nuisance alarms. Repair or recalibrate faulty instruments, and move alarm limits away from normal operating values. Add deadband (or hysteresis), so the alarm only clears once the value has moved back by a set margin. Add on-delays or off-delays where the process allows. Our process control engineering services can help with tuning and instrument problems behind repeat alarms.

4. Use state-based alarming and designed suppression with care

State-based alarming changes alarm settings to suit the plant’s state, such as startup or shutdown. Designed suppression uses logic to hold back alarms that are expected, such as low flow on a pump that has been stopped on purpose.

Both need firm safeguards. Base each rule on a written reason, test it before use and keep it under management of change. Engineers should be able to see every suppressed alarm, and alarms should return to normal on their own when the plant state changes.

5. Control alarm shelving

Shelving lets an operator temporarily remove an alarm from the active alarm list, for example while a faulty transmitter waits for repair. Because a shelved alarm is out of sight, shelving needs:

• A time limit, after which the alarm returns on its own
• Approval for high-priority or safety-related alarms
• A clear list of shelved alarms that everyone can see
• A review at every shift handover

6. Manage change and audit regularly

Keep your alarm philosophy, master alarm database and live system in line. Audit them on a set schedule, and re-measure alarm flood performance after any major change. Our DCS alarm management services cover alarm rationalisation, suppression design and system optimisation.

People matter too, because operators and engineers need to know why the system works the way it does. A DCS alarm management training course helps teams keep improvements in place.

Alarm KPI Dashboard Example

A simple dashboard lets teams track the same alarm management KPIs each month for each console and see progress at a glance.

Always note the time period, plant conditions and scope of changes. A drop in time in alarm flood is only good news if no key alarm was removed or hidden to get there.