How to Test Failover Between Dual SIMs
Dual SIMs only protect a site if the switch actually happens when the primary carrier fails, and a failover that was configured but never tested is a comforting assumption, not a backup. Testing it means forcing the primary path down on purpose and confirming the gateway notices, switches to the backup SIM, and re-establishes the link to your host, then fails back cleanly when the primary returns. This procedure is for the technician commissioning a dual-SIM gateway who wants proof, not faith, before leaving the site.
Test failover between dual SIMs in one line: To test failover between dual SIMs, verify each SIM works alone, then force the primary carrier down (pull it or block its path) and confirm the gateway detects the loss, switches to the backup SIM, and reconnects to your SCADA host. Time the switchover, watch for the site reappearing in monitoring, then restore the primary and confirm it fails back without flapping.
Prove Each SIM Works Alone First
Before testing the switch, confirm both SIMs are individually healthy, because a failover test is meaningless if the backup SIM was never working. Bring up the gateway on the primary SIM, verify it attaches on the right APN and reaches your host, then force it onto the secondary SIM and verify the same. A backup SIM that has a wrong APN, a suspended plan, or no coverage at this site will fail the real test later at the worst time, and you want to find that now while it is a configuration fix rather than an outage.
Record the signal and the reachable host for each SIM separately. Two SIMs on two carriers can see very different coverage at the same pad, which is the whole reason for carrier diversity, so it is normal for the backup to read weaker; what matters is that it reaches your host at all. The mechanics of how the second SIM stands in for the first are covered in the guide to dual-SIM carrier redundancy, and the broader switch mechanism in the explainer on cellular failover.
Force the Primary Down and Time the Switch
Now break the primary path deliberately. The cleanest way is to make the primary genuinely unreachable rather than just weak, because a marginal-but-alive primary is exactly the condition that confuses failover logic and you want a decisive test first. Depending on the gateway, that can mean removing the primary SIM, disabling its interface, or blocking its route so the gateway sees the primary as failed. Start a timer when you break it and watch the gateway's status: it should detect the loss, switch the active SIM to the backup, and re-register on the secondary carrier.
The switch is not complete when the backup attaches; it is complete when your host is reachable again through the backup. Confirm the gateway reconnects all the way to your SCADA server, not just to the carrier, and note how long the whole switchover took from the moment you broke the primary. That duration is governed by the detection and dwell settings, which is why a switch that is too slow or too fast points you at the hold-down timer, the subject of setting a failover hold-down timer.
Restore the Primary and Confirm Clean Failback
Bring the primary path back and watch what the gateway does. A well-configured gateway either holds on the working backup until a policy says to return, or fails back to the preferred primary after it has proven stable, and it should do so once, cleanly, without bouncing between SIMs. If restoring the primary makes the gateway flap back and forth, the failback timing is too aggressive and needs a dwell or hold-down adjustment, because a flapping gateway is worse than one that simply stays on the backup.
Test the marginal case too if you can: instead of a hard break, degrade the primary so it wavers, and confirm the gateway does not ping-pong. This is the failure mode that catches sites in the real world, where a primary carrier does not vanish cleanly but fades in and out. A gateway that switches decisively on a hard failure but thrashes on a marginal one is only half-commissioned.
Record the measured switchover time, the failback behavior, and the signal on each SIM. Once the site is live, a platform such as Merobix trends the gateway's connectivity, so a real failover in the field shows as a brief gap and a carrier change in the record rather than a silent event, and a site that starts flapping between SIMs becomes visible before it becomes a data-quality problem. The test proves the switch; the trend watches it work under real conditions.
Frequently Asked Questions
How do I force a dual-SIM gateway to fail over for testing?
Make the primary path genuinely unreachable: remove the primary SIM, disable its interface, or block its route so the gateway sees it as failed rather than merely weak. A hard, decisive break is the right first test because a marginal-but-alive primary is the condition most likely to confuse failover logic, and you want a clean result before testing the ambiguous case.
How long should dual-SIM failover take?
Long enough that a momentary blip does not trigger it, short enough that a real outage does not leave the site dark for long. The exact time is set by the detection and hold-down settings and is site-specific. Measure your gateway's actual switchover from the moment you break the primary to the moment the host is reachable through the backup, and tune the hold-down if it is too slow or too twitchy.
Why does my gateway keep flapping between SIMs?
Flapping means the failover and failback timing is too aggressive for a primary that wavers rather than failing cleanly. Add or lengthen the dwell or hold-down time so the gateway commits to a path before reconsidering, and require the primary to prove stable before failing back. A gateway that thrashes on a marginal link is worse than one that simply stays on the backup.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.