How to Set Up a Cellular Gateway Watchdog Reboot

Define the Right Failure Condition

The watchdog is only as good as what it watches, so pick a condition that catches the real failure. Watching for loss of cellular signal misses the worst case, which is a gateway that holds signal but cannot pass data, so the stronger test is loss of reachability to a known target such as your SCADA host or platform. If the gateway can no longer reach that target for a defined period, something is wrong even if the modem insists it has signal. This connects to the heartbeat idea, where the gateway's regular check-in is itself the health signal, described in the guide to a gateway heartbeat tag.

Choose the target carefully. Pinging a public address tests the internet path but not the path to your host, and on a private APN a public target may be unreachable by design, which would false-trip the watchdog forever. Point the watchdog at something the gateway is supposed to reach in normal operation, so a failed check genuinely means the site has lost its useful link rather than losing a path it was never meant to use.

Build a Recovery Ladder, Not Just a Reboot

Do not jump straight to a full reboot, because a reboot is the slowest and most disruptive recovery and many stuck states clear with something gentler. Build a ladder: first re-establish the data connection, then reset the modem or cellular interface, and only if those fail, reboot the whole device. Each rung is tried in order with its own timer, so a transient hiccup is fixed cheaply and only a genuinely wedged device escalates to the full reboot. This staged reconnect logic is the same principle as the backoff described in the guide to reconnect backoff for telemetry clients.

Guard against the reboot loop, which is the watchdog's own worst failure mode. A gateway at a site with genuinely no coverage will fail the reachability check no matter what it does, and a naive watchdog will reboot it forever, burning power and never recovering because the problem is not something a reboot can fix. Cap the reboots in a window, or back off the reboot interval after repeated failures, so a site that is truly down stays up long enough to be reachable when coverage returns rather than cycling uselessly. On a solar or battery site this matters even more, since endless reboots drain the power budget described in the worksheet for a remote site power budget.

Set Timers and Test the Self-Recovery

Set the timers so the watchdog rides out normal blips but reacts to a real stall. The reachability check should tolerate the ordinary gaps a cellular link has, and the escalation timers should be long enough that a momentary drop does not trigger a needless modem reset or reboot. Too twitchy and the gateway reboots itself out of transient problems it would have recovered from; too slow and a wedged site stays dark for hours. Base the timers on the site's normal connectivity behavior, not a default.

Test it by breaking the link deliberately and watching the ladder run: block the path to the host and confirm the gateway tries the connection restart, then the modem reset, then the reboot, in order, and comes back when you restore the path. Then confirm it does not loop by leaving the link broken longer and watching that the reboot backoff kicks in rather than cycling. A watchdog that has never been tested is a guess about the site's most important safety net.

Record the failure condition, the ladder, and the timers. Once live, a platform such as Merobix trends the gateway's connectivity, so a site that recovers on its own shows as a brief gap that closed without a truck roll, and a site whose watchdog is firing repeatedly shows a pattern of short outages that tells you the underlying link is marginal and needs a real fix. The watchdog buys unattended recovery; the trend tells you when the recovery is masking a deeper problem.

Frequently Asked Questions