Alarm Management Best Practices: 10 Rules for Effective Alarms
Alarm management best practices — rationalize and prioritize, kill nuisance alarms, set proper deadbands and delays, hit EEMUA targets, and implement it in the HMI.
What Is Alarm Management — and Why It Matters
A single poorly configured alarm can trigger dozens of subsequent alerts, overwhelm an operator, and mask the one signal that actually matters. The BP Texas City refinery disaster (2005) and the Buncefield fuel depot explosion (2005) are both linked, in part, to operators dealing with alarm floods at the worst possible moment. Effective alarm management best practices are not a luxury — they are a safety-critical discipline.
This guide covers the ten rules that industrial automation engineers and operations teams need to implement right now, with practical PLC and SCADA configuration recipes you can act on today.
Alarm management is the systematic process of designing, rationalizing, configuring, and continuously improving the alarm system of a process plant or manufacturing facility. For a broader foundation, read our overview of what is alarm management before working through the implementation rules below.
Rule 1: Rationalize and Prioritize Every Alarm
Alarm rationalization is the foundation of every other best practice. Without it, you are tuning noise.
Rationalization means reviewing every alarm in your system — ideally against a Master Alarm Database (MADB) — and answering three questions for each one:
- Does this alarm require operator action? If not, it should be an event log entry, not an alarm.
- What is the consequence of missing this alarm? That consequence determines priority.
- What is the required response time? That sets the on-delay and annunciation urgency.
Priority tiers most plants use:
| Priority | Consequence if missed | Typical response window |
|---|---|---|
| Critical (P1) | Injury, major equipment loss | < 5 minutes |
| High (P2) | Significant process upset | 5 – 15 minutes |
| Medium (P3) | Minor quality or efficiency impact | 15 – 60 minutes |
| Low (P4) | Informational, advisory | > 60 minutes |
EEMUA Publication 191 (the industry bible for alarm management) recommends that no more than 5% of alarms be Priority 1, and no more than 15% be Priority 2. If you currently have 40% critical alarms, your priority system is meaningless to operators.
Implementation tip (Rockwell FactoryTalk View SE / Allen-Bradley PLCs): Use the alarm priority field in the FT Alarm and Events server. Map P1 to audible alert + flashing red; P2 to audible + solid amber. Never assign audio to P3/P4 — operators habituate and ignore it.
Implementation tip (Siemens TIA Portal / WinCC): Configure alarm classes in the WinCC alarm system editor. Use the Priority field (0–16) mapped to your four-tier scheme. A priority class tag block makes global changes easy when your rationalization review updates tiers.
Rule 2: Eliminate Nuisance and Chattering Alarms
A nuisance alarm is any alarm that fires without requiring a meaningful operator response. A chattering alarm is one that trips and resets repeatedly in a short period because the process variable is oscillating around the setpoint.
Nuisance alarms are the single largest driver of alarm floods. EEMUA 191 states that operators in flood conditions acknowledge alarms without reading them — negating the entire point of the system.
Identify chattering alarms using your historian or alarm log:
- Export your alarm journal for the last 30 days.
- Sort by alarm tag and count transitions (trip + reset = one cycle).
- Any tag with more than 10 transitions per day is a chattering alarm and needs intervention.
Three proven fixes:
| Problem | Fix |
|---|---|
| Process variable oscillates around setpoint | Add a deadband (see Rule 4) |
| Sensor noise causes false trips | Add an on-delay (see Rule 4) |
| Alarm fires during normal startup/shutdown | Use state-based alarming — disable the alarm when the unit is in a non-running state |
In Allen-Bradley Studio 5000 / FactoryTalk Alarms: The ALMA (Alarm Analog) and ALMD (Alarm Digital) instructions have built-in InAlarm, Suppressed, and Shelved bits. Use the Delay input on ALMD for on-delays and the Deadband input on ALMA to create hysteresis without custom ladder logic.
In Siemens S7 with WinCC: Alarm hysteresis is configured per limit in the tag properties. Under the Limits tab, set the "Hysteresis" value as an absolute or percentage value of the engineering range. For time delays, use a TON (on-delay timer) block in your PLC program that gates the alarm bit rather than connecting the process variable directly to the alarm tag.
Rule 3: One Alarm Per Event — Kill Redundancy
Multiple alarms reporting the same underlying event is called alarm flood multiplication. A pump trip might fire a low-flow alarm, a low-pressure alarm, a motor protection alarm, and a high-temperature alarm — all from a single root cause. The operator sees four alarms when the relevant information is one: the pump tripped.
How to implement consequence-based alarming:
- Identify cause-and-effect relationships in your P&IDs.
- Suppress downstream consequence alarms when a root-cause alarm is active.
- Use alarm suppression logic (often called first-out logic or cause-and-effect suppression) in your PLC or SCADA layer.
First-out logic in ladder (generic pattern):
(Pump_Running = FALSE AND Pump_Trip_Alarm = TRUE)
→ Suppress: Low_Flow_Alarm, Low_Pressure_Alarm, High_Temp_Alarm
In FactoryTalk View and most modern SCADA platforms, this is called alarm suppression by source and can be configured in the alarm group settings without modifying PLC code — preferred because it keeps business logic in the HMI/SCADA layer where operations can maintain it.
Rule 4: Set Proper Deadbands and On/Off-Delays
Deadbands and delays are the primary technical tools for eliminating chattering. Getting them right requires understanding your process — not just copying a template value.
Deadband (hysteresis): Prevents re-annunciation when the variable returns to near-setpoint. Set the deadband so that normal process variability does not cause the alarm to toggle.
- Start with the process standard deviation over a 24-hour normal operating window.
- Set deadband to 2× the standard deviation as a starting point.
- Validate: the alarm should not re-trip during routine process fluctuation.
On-delay: Prevents momentary transients (sensor glitches, startup spikes) from generating alarms. Typical values:
| Signal type | Suggested on-delay starting point |
|---|---|
| Analog (flow, pressure, temperature) | 3 – 10 seconds |
| Digital (motor status, valve position) | 0.5 – 2 seconds |
| Slow processes (level, temperature in large vessels) | 10 – 30 seconds |
Off-delay: Less commonly used but valuable for digital alarms where a brief return-to-normal followed by re-alarm indicates a real problem (e.g., a valve hunting). An off-delay keeps the alarm active for a defined period after the condition clears, reducing nuisance acknowledgements.
In TIA Portal: The analog alarm limit blocks (LimitMonitor FB or direct tag limits in WinCC) expose both Hysteresis and a Delay parameter. For digital alarms coded in ladder/FBD, wire a TON block with a configurable PT preset stored in a DB tag so operators can tune it from HMI without PLC download.
In Studio 5000 with ALMA instruction: ALMA.HH.Deadband, ALMA.H.Deadband, ALMA.L.Deadband, and ALMA.LL.Deadband are individual per-limit. The ALMA.InAlarm bit will not set again until the PV returns past the deadband. Use the .Delay parameter for on-delay in seconds.
Rule 5: Define and Track EEMUA Performance Targets
You cannot improve what you do not measure. EEMUA Publication 191 and ISA-18.2 both define quantitative alarm performance targets. Meet these, and your system is considered well-managed. Exceed them, and you have an alarm flood problem.
Key EEMUA 191 performance targets:
| Metric | Acceptable | Manageable | Overloaded |
|---|---|---|---|
| Average alarm rate (steady state) | < 1 alarm / 10 min | 1 – 2 alarms / 10 min | > 2 alarms / 10 min |
| Peak alarm rate (10-min window) | < 10 alarms / 10 min | 10 – 20 alarms / 10 min | > 20 alarms / 10 min |
| % alarms acknowledged within 10 min | > 90% | 75 – 90% | < 75% |
| Stale (standing) alarms > 24 hrs | < 5 | 5 – 10 | > 10 |
| Top-10 most frequent alarms | < 1% of total alarms | — | — |
Build these KPIs into your SCADA: Most modern SCADA platforms (Ignition, FactoryTalk View SE, WinCC Unified) have built-in alarm analysis modules. Configure a daily report that emails the top 10 most frequent alarms, current standing alarm count, and average alarm rate by shift. Make it visible — post it in the control room.
Rule 6: Document and Assign Ownership
Every alarm must have a documented rationalization record in your MADB. At minimum, each record includes:
- Tag name and description
- Alarm priority and basis for that priority
- Setpoint and basis (e.g., equipment protection limit from vendor datasheet)
- Deadband and delay values with justification
- Required operator response (step-by-step, not vague)
- Responsible owner (engineering discipline — not a person's name, which changes)
- Last review date
Without documentation, rationalization degrades over time. A new engineer lowers a setpoint to "stop the nuisance alarm." Six months later nobody knows why the setpoint is where it is, and you are back to square one.
Ownership also means assigning a process discipline (e.g., Instrumentation, Mechanical, Process Engineering) that must approve any change to that alarm's configuration. Tie this to your management of change (MOC) process.
Rule 7: Use Alarm Shelving Correctly
Shelving temporarily suppresses an alarm for a defined period, typically used when equipment is known to be in a degraded state and the alarm would otherwise flood during planned operations. It is distinct from suppression (which is programmatic/automatic) and disabling (which removes the alarm entirely).
Rules for shelving:
- Shelving should require operator authorization and a reason code.
- Maximum shelving duration should be defined by policy (commonly 8–24 hours; never indefinite).
- Shelved alarms must appear on a dedicated HMI display so operators know what is suppressed.
- A shelved alarm must auto-reinstate at the end of the period even if no action is taken.
- Shelving counts and durations should appear in the alarm KPI report — persistent shelving is a flag for rationalization review.
In FactoryTalk Alarm and Events: The ALMD/ALMA instruction Shelved bit can be set via an HMI button. Set the ShelveDuration parameter to your maximum allowed time. Wire the shelf status bit to a summary display tag.
In Ignition (Inductive Automation): The alarm journal and active alarm table both surface shelved state natively. Use the Alarm Status Table component's built-in shelving workflow — it enforces duration and logs the operator ID and reason automatically.
In WinCC Unified: Alarm suppression/shelving is managed via the AlarmControl widget's context menu. Script the maximum duration enforcement in a global module function triggered on shelve action.
Rule 8: Audit Alarm Data Continuously
A one-time rationalization is a starting point, not a destination. Alarm systems drift. Setpoints get copied from old projects. Contractors add diagnostic alarms during commissioning and forget to rationalize them. Equipment ages and noise floors change.
Continuous audit activities:
- Weekly: Review the top-10 most frequent alarm list. Any new entrant to the top-10 gets an immediate investigation.
- Monthly: Run a standing-alarm report. Any alarm active for more than 30 days without a shelving record is either a process problem or a bad alarm — both require action.
- Quarterly: Review overall KPIs against EEMUA targets. Trend the alarm rate over time. If it is rising, find the source.
- Annually (or after major MOC): Full rationalization review of all alarms modified or added in the prior year.
Build standing-alarm reports in your HMI. In most SCADA platforms this is a filtered view of the active alarm table sorted by alarm age (time in alarm). In Ignition, this is a named query against the alarm_event_data table filtered on event_type = 0 AND clear_time IS NULL with a duration column calculated as NOW() - active_time. Surface it on a dedicated alarming KPI screen visible to the operations supervisor.
Rule 9: Map Your Program to the ISA-18.2 Lifecycle
ISA-18.2 (the ANSI/ISA standard for alarm management) defines a ten-stage lifecycle that covers everything from philosophy through rationalization, detailed design, HMI implementation, operation, monitoring, maintenance, and management of change. The EEMUA 191 guide aligns with this framework.
The stages most plants skip — and the consequences:
| Skipped stage | Consequence |
|---|---|
| Alarm philosophy | No baseline — every engineer does something different |
| Rationalization | Undocumented setpoints, wrong priorities, no response procedures |
| HMI implementation review | Alarms not visible or annunciated correctly on operator displays |
| Monitoring & KPI reporting | Problems go undetected until an incident |
| Management of change | Rationalized alarms get corrupted by undocumented changes |
Your alarm philosophy document should be written before any PLC or HMI programming begins on a new project, and it should be the governing document for every alarm decision. If you are working on a legacy system, write a retroactive philosophy that captures current intent, then use it as the baseline for ongoing rationalization.
For a deeper look at how alarm management integrates with your broader SCADA configuration, see our SCADA best practices guide and our HMI design best practices guide.
Rule 10: Train Operators — and Keep Training Them
The best-configured alarm system fails if operators do not understand it. Operator training for alarm management covers three areas:
1. Alarm response procedures: Every P1 and P2 alarm should have a written response procedure either printed in a binder or — better — accessible directly from the alarm detail popup in the HMI. In Ignition and WinCC Unified, you can add a Notes or Help field to each alarm that displays the response procedure when the operator clicks on the alarm. This is one of the highest-value HMI improvements you can make.
2. Shelving and suppression procedures: Operators must know what shelving is, when it is appropriate, and critically — what it means that an alarm is shelved. A common failure mode: operator shelves an alarm, handover occurs, next operator does not check the shelved alarm list, and the underlying problem is missed.
3. Alarm flood response: Train operators on what to do when they face a flood — how to identify the root cause alarm, how to use suppression tools, and when to call for supervisor support. Tabletop exercises with recorded alarm floods (pulled from your historian) are effective.
For guidance on building operator-friendly displays that support alarm response, see our HMI programming tutorial and PLC programming best practices guide.
Frequently Asked Questions
What are alarm management best practices?
Alarm management best practices are the engineering and operational disciplines used to design, configure, and continuously improve industrial alarm systems. The core practices are: rationalize every alarm against a documented basis, prioritize alarms so only critical alarms demand immediate response, eliminate nuisance and chattering alarms using deadbands and on-delays, suppress redundant consequence alarms, track performance against EEMUA 191 targets (under one alarm per ten minutes in steady state), document all alarms in a master database, and review alarm performance data continuously. These practices are codified in ISA-18.2 and EEMUA Publication 191.
How do you reduce nuisance alarms?
The most effective methods for reducing nuisance alarms are: (1) add deadbands to analog alarms so that normal process variation does not cause repeated tripping; (2) add on-delay timers so transient spikes do not generate alarms; (3) use state-based alarming to suppress alarms that are irrelevant in a given operating mode (e.g., startup, shutdown, standby); (4) implement cause-and-effect suppression to prevent downstream consequence alarms from flooding when a root-cause alarm is already active; and (5) review your top-10 most frequent alarms weekly and address each one. Most plants can reduce their alarm rate by 50–80% by targeting their top-20 most frequent alarms alone.
What is a good alarm rate?
According to EEMUA Publication 191 and ISA-18.2, an acceptable steady-state alarm rate is fewer than one alarm per ten minutes per operator position. A rate of one to two alarms per ten minutes is considered manageable. Anything above two alarms per ten minutes in steady state is classified as overloaded. During upset conditions, a peak of fewer than ten alarms in any ten-minute window is the target — beyond that, operators enter flood conditions where response reliability drops significantly.
What is alarm shelving?
Alarm shelving is a temporary, operator-initiated suppression of a specific alarm for a defined period. It is used when the alarm is known to be active due to a planned condition — for example, equipment under maintenance that would otherwise flood the alarm list. Shelved alarms should still appear in a dedicated shelved-alarm display, require an operator reason code, and automatically reinstate after a maximum defined duration (commonly 8–24 hours). Shelving is distinct from disabling (permanent removal) and programmatic suppression (automatic logic-driven suppression). Misuse of shelving — particularly indefinite or undocumented shelving — is a recognized contributing factor in process safety incidents.
Last updated: June 2026. Standards referenced: ISA-18.2-2016, EEMUA Publication 191 (3rd edition).
