SCADA Alarm Management
Comparison (2026)

Back to Blog

Why Alarm Management Decides Whether Your SCADA Works

Most SCADA evaluations obsess over screens, drivers, and licensing - then treat alarming as a checkbox. That is backwards. The alarm system is the one part of SCADA that runs your operation when nobody is looking at the screen, which for a distributed operation is most of the time.

The industry has a name for what happens when alarming is treated as a checkbox: alarm fatigue. Benchmarks commonly cited from ISA-18.2 and EEMUA 191 target roughly one alarm per operator per 10 minutes in steady state - about 144 per day. Real-world systems that have never been rationalized routinely generate ten times that, and every incident review in the process industries tells the same story: the critical alarm was present, buried under hundreds of nuisance alarms, acknowledged in a batch, and acted on too late.

ANSI/ISA-18.2 - the standard for management of alarm systems in the process industries - exists to prevent exactly that. It defines a lifecycle: philosophy, identification, rationalization, design, implementation, operation, maintenance, and monitoring. You do not need a refinery-sized program to benefit from it. You need a SCADA platform whose alarm engine gives you the ISA-18.2 building blocks - priority tiers, deadbands, delays, suppression, shelving with auto-return, and alarm analytics - without a development project. That is the comparison this article makes.

Alarm Fundamentals: HIHI / HI / LO / LOLO, Deadbands, and Priority

Every serious alarm engine starts with four-level analog setpoints. A tank level or line pressure gets a HI (pre-alarm - operator should investigate) and a HIHI (critical - immediate action required), plus LO and LOLO on the low side. The two-tier structure is what lets you assign different priorities, different notification channels, and different escalation behavior to "worth a look" versus "get out of bed." A platform that offers only a single high/low pair forces every deviation to be either ignored or treated as an emergency.

Three mechanisms keep those setpoints from generating noise:

• Deadband (hysteresis): the alarm clears only after the value returns a configurable margin past the setpoint. Without it, a pressure hovering at the limit generates a "chattering" alarm that triggers and clears dozens of times an hour.
• On-delay / off-delay: the value must violate the setpoint for N seconds before the alarm activates. This filters transients - a pump start spike, a momentary flow surge - that need no operator response.
• Priority tiers: ISA-18.2 recommends three to four priorities, assigned by consequence severity and time to respond. A good rule of thumb from rationalization practice: the vast majority of alarms should land in the lowest priority, and only a small fraction in the highest.

When you evaluate any platform, ask to see all three configured on a single tag in the live product. If the answer involves scripting, that is your first data point.

How Alarm Management Differs Across Platform Categories

When you evaluate alarm management, look across seven dimensions: setpoint depth, nuisance filtering, suppression, shelving, escalation, delivery channels, and alarm analytics. The table below shows how the major platform categories tend to handle each - differences here are architectural, not cosmetic, and they do not show up on a features one-pager.

Capability	Cloud-native monitoring platform	Configurable / code-first SCADA	Traditional HMI/SCADA	Enterprise DCS-class
HIHI/HI/LO/LOLO setpoints	Native, per tag	Native, per tag	Native	Native
Deadband + time delays	Built-in, no code	Built-in	Built-in	Built-in
ISA-18.2 shelving (auto-unshelve)	Built-in	Built-in	Varies by product/version	Built-in
State-based suppression	Smart suppression built-in	Via expressions/scripting	Limited or scripted	Strong, config-heavy
Escalation chains	Built-in, no code	Configurable pipelines	Add-on notification software	Add-on or custom
SMS/email delivery	Native, built-in	Modules + your infrastructure	Third-party add-on	Third-party add-on
Alarm history analytics	Built-in reports	Queryable, build your own	Basic logs	Dedicated suites available
Setup effort for all of the above	Hours	Days–weeks (engineering)	Weeks + add-ons	Months + integrator

Two honest observations from that table. First, a configurable, code-first SCADA can be genuinely powerful - its notification pipelines can express almost any escalation logic you can draw on a whiteboard, and for complex facilities with in-house SCADA engineers it is among the most flexible options available. The trade-off is that the flexibility is delivered as an engineering toolkit: someone has to design, build, and maintain those pipelines, and SMS delivery depends on infrastructure you supply.

Second, DCS-class alarm management is the gold standard for large continuous plants. Refineries and chemical complexes running enterprise control systems, often paired with dedicated alarm-management suites, get rationalization databases and analytics that no mid-market SCADA matches. The cost is proportionate: integrator-led projects, multi-month timelines, and budgets that only make sense at plant scale.

Where does a cloud-native monitoring platform fit? The alarm engine ships with four-level setpoints, deadbands and delays, smart suppression, ISA-18.2-aligned shelving, a live annunciator view, escalation chains, and built-in SMS/email delivery as standard features - configured through the browser rather than built in code. That is the approach Merobix takes; the full plan-by-plan matrix is on the plans page, and higher tiers add redundancy and SIEM integration for operations with formal security requirements.

Which Platform Is Best for Alarm Rationalization?

Rationalization is the ISA-18.2 step where you review every configured alarm and ask: what is the consequence, what is the operator response, and what priority does it deserve? Alarms with no defined response get deleted - typically the single biggest noise reduction available. The best platform for rationalization is therefore the one that makes this review cheap to run and easy to enforce.

Three capabilities matter most:

• Alarm history analytics - a report of your most frequent alarms by tag, so you attack the "bad actors" first. In most unrationalized systems, a handful of tags generate the majority of all alarm traffic.
• Fast reconfiguration - rationalization decisions (change a priority, widen a deadband, add a delay, delete an alarm) should be minutes of browser work, not a change order to an integrator.
• Shelving with an audit trail - so operators have a sanctioned way to park a nuisance alarm during the weeks before rationalization catches up with it, without anything being silently disabled.

For plant-scale programs, dedicated rationalization suites paired with a DCS remain the most complete tooling. For distributed operators with dozens of remote sites, Merobix builds the loop into the platform: the alarm-history report identifies bad actors across every site at once, and fixes deploy from the same dashboard. Operators running oilfield alarm monitoring across a lease portfolio can typically cut alarm volume dramatically in the first month simply by working the frequency report top-down.

Alarm Suppression vs Shelving: What Vendors Actually Offer

These two words get used interchangeably by vendors, and they should not be. Suppression is system-initiated: the platform hides an alarm because a designed condition says it is not meaningful right now - the well is shut in for workover, the parent breaker alarm is already active, the site is in planned maintenance. Shelving is operator-initiated and temporary: the operator parks a nuisance alarm for a defined interval, and ISA-18.2 requires that it automatically return when the timer expires. Suppression is engineering; shelving is a pressure-relief valve for the operator - and the auto-unshelve requirement is what keeps it from becoming a way to permanently silence alarms.

When comparing how platforms handle alarm suppression, ask these five questions:

• Can suppression be driven by equipment state (shut-in, maintenance mode), not just manually toggled?
• Does a parent alarm suppress its consequential child alarms during a cascade?
• Is shelving time-limited with automatic return, per ISA-18.2 - or is "disable alarm" the only tool offered?
• Is every suppression and shelving action logged with user, timestamp, and duration for incident review?
• Can a supervisor see, in one view, everything currently suppressed or shelved across all sites?

Merobix answers yes to all five: smart suppression handles state-based and cascade cases, shelving is ISA-18.2-aligned with automatic return, and the annunciator view shows active, acknowledged, suppressed, and shelved alarms across every site on one screen. On many older HMI-centric systems, several of these capabilities arrive only as scripting projects or third-party add-ons - which in practice means they often never get implemented.

Alarm Escalation and configurable SMS and email alerts: SMS vs Push vs Email

Detection is worthless without delivery. The escalation chain - who gets notified, in what order, and what happens when they do not respond - is where alarm management meets the real world of night shifts, dead zones, and phones on silent.

Channel	Typical Latency	Depends On	Common Failure Mode	Best Use
SMS	Seconds	Cellular network only	Coverage dead zones	Primary critical-alarm channel
Email	Seconds–minutes	Data connectivity	Ignored outside work hours; spam filters	Documentation and lower priorities
Mobile push	Seconds	App installed, notifications enabled, data coverage	App killed by OS; permissions revoked	Convenience layer, never sole channel
Voice call	Seconds–minutes	Cellular network	Screened as spam	Final escalation step

The engineering takeaway: SMS is the backbone because it works on any phone with one bar of signal and no app, but no single channel is guaranteed - which is why the real feature to compare is the escalation chain, not the channel list. A proper chain looks like: HIHI alarm fires, SMS and email go to the on-call operator within seconds; if unacknowledged after a configurable timeout, the alarm re-routes to the backup; still unacknowledged, it escalates to the supervisor. Acknowledgment is tracked in the platform, so the 6 AM question "who knew, and when?" has an audit-trail answer. For the engineering behind making sure the message itself gets through, see our deep dive on SCADA alarm integrity and delivery.

This is also where platform categories diverge most sharply. A cloud-native monitoring platform typically delivers SMS and email alerts through built-in, no-code escalation chains with acknowledgment tracking - the approach Merobix takes, with escalation and delivery shipped as standard features. A configurable, code-first SCADA can achieve equivalent behavior through notification pipelines, provided you engineer and maintain them along with the SMS infrastructure they depend on. Developer-oriented data platforms document email, SMS, and voice notification support, with escalation logic typically implemented by your own developers. And many HMI-centric systems hand the entire problem to third-party notification software bolted on beside the SCADA - one more system to license, patch, and keep in sync with your call-out list.

Alarm Handling for Operators Managing Multiple Systems

The hardest alarm problem is not one plant with one control room - it is one operator responsible for thirty wells, twelve pump stations, or a portfolio of small facilities, each historically running its own isolated HMI. Per-system alarm handling multiplies consoles, logins, and call-out lists until something falls through the gap between systems.

The fix is architectural: a unified alarm inbox that aggregates every alarm from every site and every driver into one prioritized, filterable list. Merobix does this natively - alarms from all sites, collected across drivers for the major industrial protocols, land in a single annunciator view with per-site routing rules, so the pumper responsible for each lease gets exactly their alarms and the operations manager sees the whole board. Whether cloud-hosted or on your own servers, the aggregation works the same way.

Checklist for evaluating multi-system alarm handling:

• One inbox for all sites, sortable by priority, site, and time - no per-site logins
• Per-site and per-role routing, so notifications follow responsibility, not geography
• Escalation chains that keep working when the primary contact is unreachable
• Site-level suppression for planned maintenance, so a workover does not flood the board
• Cross-site alarm history you can search and export for incident and compliance review

Frequently Asked Questions