SCADA High Availability & Redundancy
Buyer's Guide (2026)

Back to Blog

What Does High Availability Mean in SCADA?

High availability (HA) in SCADA means the monitoring and alarming system keeps operating through hardware failures, software crashes, network outages, and maintenance - with no gap an operator would notice. In practice, it is achieved through redundancy: a second copy of every critical component (server, historian, communication path) that takes over automatically when the primary fails. Disaster recovery (DR) is the related but distinct discipline of restoring the system after a larger event - a fire, a flood, a ransomware incident - typically from replicated data at a second location.

The stakes are asymmetric. A SCADA outage does not usually break anything by itself - the PLCs keep running their logic locally. What you lose is visibility and alarming. If a high-pressure alarm would have fired during the outage window, nobody gets the call. For pipelines, gas processing, water systems, and any operation with environmental or safety exposure, that window is the entire risk. This is why reliability-focused buyers evaluate HA before features: a feature you cannot see during an outage does not exist. This article goes deep on the redundancy layer specifically.

Availability is usually expressed in "nines." The difference between them is bigger than it looks:

• 99% uptime - up to 87.6 hours of downtime per year. Unacceptable for continuous operations.
• high availability - up to 8.8 hours per year. The standard commitment for serious SCADA platforms; Merobix cloud plans carry availability governed by the applicable service agreement.
• 99.99% uptime - under 53 minutes per year. Requires fully redundant everything, including networks and power, and is typically the territory of purpose-built control-room deployments.

Hot Standby vs Warm Standby vs Cold Standby

The three standby models differ in how fast the backup takes over and how much data you lose. Hot standby fails over in seconds with near-zero data loss; cold standby takes hours and loses everything since the last backup. This single architectural choice determines whether a server failure is a non-event or an incident report.

Attribute	Hot Standby	Warm Standby	Cold Standby
Backup state	Running, fully synchronized in real time	Running, synchronized periodically	Powered off or bare hardware/image
Failover trigger	Automatic - heartbeat detection	Automatic or manual	Manual - someone drives to the server room
Typical recovery time	Seconds	Minutes	Hours to days
Data loss on failover	Near zero	Minutes of history	Everything since last backup
Alarm coverage gap	Effectively none	Short gap possible	Full gap until restore completes
Relative cost	Highest - duplicate licensed server	Moderate	Lowest upfront, highest in a real failure

Hot standby runs a second, fully licensed SCADA server in parallel with the primary. The pair exchanges a heartbeat signal and continuously synchronizes runtime state - tag values, alarm states, operator sessions. When the primary stops responding, the standby promotes itself within seconds and clients reconnect automatically. Operators may see nothing more than a brief refresh. This is the model included in the Merobix Enterprise plan for on-premise deployments.

Warm standby keeps a second server running with periodic synchronization - configuration replicated nightly, historian shipped in batches. Failover is faster than a cold restore but you lose the data between synchronizations, and the alarm engine may need minutes to rebuild state. It is a reasonable compromise for operations that can tolerate a short blind window.

Cold standby is a backup server on a shelf, or a VM image and last night's backup. It is what most operations actually have, usually without admitting it. In a real failure the recovery involves finding the image, restoring it, re-licensing the software, re-pointing the field communications, and discovering which parts of the configuration were newer than the backup. Budget hours at best.

How SCADA Failover Actually Works

Automatic failover rests on three mechanisms working together: failure detection, state synchronization, and client redirection. Understanding them tells you which vendor claims are real and which are marketing.

Failure Detection

The redundant pair exchanges a heartbeat - typically every one to five seconds over a dedicated link. Missed heartbeats past a threshold trigger promotion of the standby. The hard problem is split-brain: if the heartbeat link itself fails while both servers are healthy, both may believe they are primary, and both may poll the PLCs and log conflicting history. Mature implementations use a second arbitration path (a network witness or shared quorum) to prevent it. Ask every vendor how their redundancy handles split-brain; a blank look is diagnostic.

State Synchronization

Failover is only seamless if the standby already knows everything the primary knew: current tag values, alarm acknowledgment states, setpoint changes, and user sessions. Configuration synchronization (replicating projects and tag databases) is table stakes; runtime synchronization is what separates hot standby from warm. Alarm state matters most - if acknowledgments do not replicate, a failover can re-annunciate hundreds of already-handled alarms, burying operators at exactly the wrong moment.

Client and Field Redirection

Operator clients and field communications must find the new primary without manual intervention. Web-based clients handle this most gracefully - the browser reconnects to a service address that now routes to the standby. Thick-client architectures need failover lists configured on every workstation. On the field side, the standby must take over polling of PLCs and RTUs without device reconfiguration, which is why redundant SCADA pairs share a virtual address or the drivers themselves manage the switch. Our SCADA server guide covers the underlying server architecture in more depth.

Historian Replication: Don't Lose the Data

Server failover protects live monitoring; historian replication protects the record. If your historian runs only on the primary server, every failover - even a clean one - leaves a hole in the trend data, and holes in trend data become holes in regulatory reports and production accounting.

Three patterns exist. Dual-write historians record on both members of the redundant pair simultaneously, then reconcile - no gap, at the cost of duplicate storage. Store-and-forward buffering at the data source (the gateway or driver layer) holds data during any server outage and backfills when the historian returns - this also covers network outages, which are far more common than server failures. Replication to a second site copies the historian to a geographically separate location for disaster recovery. Large multi-site operators often add historian federation on top - querying several site historians as one logical database - which Merobix supports on the Enterprise plan.

When evaluating platforms, ask one concrete question: if the historian is unreachable for four hours, what happens to those four hours of data? The right answer involves buffering at the edge and automatic backfill, not "the data is lost."

SCADA Redundancy Models: How Delivery Differs

Genuine redundancy is available across cloud and on-premise SCADA architectures - the differences are in how it is delivered, who maintains it, and whether it is included in the price or licensed separately. Here is how the common models compare:

Architecture	Redundancy Model	Backup Licensing	Uptime SLA	Who Maintains It
Merobix Cloud	Redundant hosted infrastructure, managed by vendor	Included - flat plan	99.9% target	Merobix
Merobix Enterprise On-Prem	Hot standby server pair, air-gap compatible	Included in Enterprise plan	Architecture-dependent (your infrastructure)	Your team, with Merobix support
Gateway-pair on-premise	Master/backup gateway pair with automatic failover	Often licensed per additional gateway	None - self-hosted	Your team / integrator
Application-engine on-premise	Redundant application engines, object-level failover, tiered historians	Separately licensed components	None for on-prem; cloud offerings vary	Your team + integrator
PLC-vendor HMI/SCADA on-premise	Redundant HMI servers and data servers	Separately licensed	None - self-hosted	Your team + integrator

Gateway-pair redundancy is one of the more accessible on-premise models: a master/backup gateway pair with automatic failover that is straightforward to document and deploy. If you have an in-house team comfortable running servers, this model is reasonable to stand up and genuinely reliable. The trade-off is that it is still your infrastructure: your OS patching, your certificates, your split-brain testing, and no vendor uptime SLA.

Application-engine redundancy offers arguably the deepest redundancy architecture available on-premise - failover at the individual application-object level, redundant data acquisition, and tiered historian replication. It is the reference design for refinery and power-plant control rooms, and for that class of facility it has earned its reputation. The cost is complexity: these deployments are integrator-led, multi-month projects with commensurate budgets.

PLC-vendor HMI/SCADA redundancy provides solid redundant-server options that integrate tightly with a given PLC ecosystem. It makes the most sense where the plant is already standardized on that hardware and on-site IT support exists at each facility.

Merobix approaches the problem from the opposite direction: for cloud deployments, redundancy is not something you buy, configure, or test - it is built into the hosted platform and backed by a contractual availability commitment governed by the applicable service agreement, with gateway-level store-and-forward buffering protecting data through network outages. For operations that require on-premise deployment - air-gapped networks, strict data residency - the Enterprise plan includes hot standby redundancy on your servers or VMs rather than licensing it as an add-on. If you need object-level failover granularity across a refinery-scale control room, a dedicated on-premise application-engine architecture remains an established choice. What Merobix eliminates is the scenario where redundancy was quoted, deprioritized to save budget, and quietly dropped - the plan either includes it or the SLA covers it. The full feature matrix is on the plans page.

Cloud SLA vs On-Premise Redundancy: Which Model Fits You?

The choice is really about who carries the operational burden of staying up. With a cloud SLA, the vendor owns redundancy end to end - infrastructure, failover testing, patching, monitoring - and is contractually accountable for the result. With on-premise redundancy, you own all of it and gain something the cloud cannot give you: complete control, air-gap compatibility, and full data residency on your own hardware.

Choose cloud with an SLA when your sites are distributed, your connectivity is cellular, and you do not have (or do not want to fund) a team to babysit redundant server pairs. An availability commitment governed by the applicable service agreement from a vendor whose business depends on meeting it will beat the real-world uptime of most self-maintained single servers - and of a surprising number of self-maintained redundant pairs whose failover was last tested at commissioning. Cloud deployments are also quick to stand up compared with an on-premise rollout; Merobix cloud deployments are stood up on a timeline scoped to your site count, connectivity, and integration requirements.

Choose on-premise redundancy when policy or physics demands it: air-gapped control networks, contractual data-residency requirements, or facilities where monitoring must survive a total WAN outage. In that case, buy hot standby, put the pair on independent power and network paths, and put failover testing on the maintenance calendar - quarterly, unannounced, during business hours. Redundancy that is never tested is cold standby with better marketing. The full architectural trade-off is covered in our cloud vs on-premise SCADA comparison, and Merobix supports both models - same platform, same team.

What to Demand in a SCADA SLA

An SLA is only as good as its specifics. Before signing with any vendor - Merobix included - get these items in writing:

• A specific uptime number (99.9% or better) measured monthly, not annually - annual measurement lets a vendor burn the whole downtime budget in one bad week.
• A definition of "down" that includes degraded service: if dashboards load but alarms are not delivering, you are down.
• Alarm delivery commitments - Merobix targets SMS and email alarm delivery within a minute; whatever your vendor commits to, get the number on paper.
• Scheduled maintenance terms - advance notice, defined windows, and whether maintenance counts against the SLA.
• Data durability language - what happens to historian data during an outage, and how backfill works.
• Remedies with teeth - service credits at minimum, termination rights for chronic misses.
• Security posture behind the SLA - uptime and security are inseparable; review the vendor's security architecture with the same rigor.

Frequently Asked Questions