Failover is the event a redundant SCADA system exists for: the moment the backup takes over because the primary has failed. It is easy to describe in one sentence but involves a careful sequence of detection, decision, and handoff that determines whether the switch is invisible or disruptive. This guide walks through server and application-level SCADA failover from start to finish - how a failure is detected, how the system decides to switch, how the takeover happens, and how operators and field devices end up talking to the new primary.
SCADA Failover in one line: SCADA failover is the automatic process by which a backup server takes over the primary role when the active server fails. It runs in a sequence: the system detects the failure through missed heartbeats and health checks, decides that a switch is warranted, promotes the backup to primary, and then reconnects operator clients and field devices to the new primary so supervision continues.
Failover begins with detection, and detection is deliberately cautious because switching when nothing was actually wrong is its own kind of failure. The backup watches the primary through a continuous heartbeat carried over the dedicated link between them, plus health checks that confirm the primary is not just alive but actually doing its job - polling the field, serving clients, and writing to the historian. A single missed heartbeat is not enough to act on, because a brief network hiccup can cause one. Instead the system waits for a run of missed heartbeats or a failed health check over a defined interval before concluding the primary is genuinely down.
This detection window is a tuning tradeoff. Set it too short and the system becomes twitchy, failing over on transient glitches and causing needless disruption. Set it too long and real outages drag on while everyone waits for the switch. Good designs also distinguish between kinds of failure: a primary that has crashed outright is a clear case, but a primary that is running yet unable to reach the field or has lost the sync link is murkier, and the logic has to avoid mistaking a communication problem between the two nodes for a dead primary - the situation that can lead to a split-brain if both nodes conclude the other is gone.
Once detection concludes the primary has failed, the system commits to the switch. The backup promotes itself to primary: it takes on the primary role, begins actively polling the field devices, and starts serving as the authoritative source of the process picture. In a hot-standby arrangement this handoff is fast and clean because the backup already holds a current copy of the state - tag values, active alarms, and trend buffers carry across so nothing has to be rebuilt. In warmer or colder arrangements the new primary must first catch up, reconnecting to the field and rebuilding an accurate view before it can be trusted, which stretches the handoff from seconds into minutes.
A crucial part of deciding to switch is ensuring only one node ends up as primary. If both the primary and backup somehow believe they should be in charge - typically because the link between them broke rather than the primary itself - they could both start commanding the field, which is dangerous. Robust failover therefore relies on a tiebreaker such as a quorum witness, or on redundant heartbeat paths, so the decision to promote the backup is only made when the system can be confident the old primary is truly out of service and will not keep acting as one.
A completed failover is not finished until everything that talked to the old primary is talking to the new one. Operator clients need to follow the primary role to the backup server, which is usually handled by pointing clients at a shared address or a redundancy-aware connection so they reconnect automatically rather than needing an operator to log in somewhere else. On a well-built system the operator sees little more than a brief reconnection and perhaps a status indicator noting that the backup is now active; the screens, tags, and alarm list they were watching come back populated because the new primary carried the state across. On the field side, RTUs and PLCs that were reporting to the primary must now be polled by the new primary, which either takes over the same communication endpoint or re-establishes its own sessions to the devices.
This is where SCADA failover differs from comms-only failover such as cellular failover. Cellular failover swaps a broken network link for a backup link and is confined to connectivity - the same server keeps running throughout. SCADA failover replaces the server or application that is the brain of the supervisory system, so it has to move an entire running role, its state, and every client and device relationship from one machine to another. With a cloud SCADA platform like Merobix, this whole sequence is handled by the service: field devices report to a stable cloud endpoint and operators use a browser session that survives an underlying node failure, so a healthy instance already carrying the live state takes over without anyone reconnecting anything by hand.
A failover is triggered when the backup concludes the primary has failed - typically after a run of missed heartbeats over the dedicated link between them, or a failed health check showing the primary is no longer doing its job. The system waits for sustained evidence rather than acting on a single missed beat, so a brief network glitch does not cause a needless switch. Only when the failure is confirmed does the backup promote itself to primary.
On a well-designed system, very little - usually a brief reconnection and a status indicator showing the backup is now the active server. Because the backup carried the live state across in a hot-standby setup, the screens, tag values, and alarm list come back populated rather than blank. The goal is that operators keep working with only a momentary interruption rather than losing their view of the process.
Cellular failover is comms-only - it swaps a failed network link for a backup link while the same server keeps running. SCADA failover replaces the server or application that supervises the whole system, moving an entire running role, its state, and every client and device connection from one machine to another. They solve different problems and a system can use both: cellular failover to keep the link up, SCADA failover to keep the supervisory server up.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.