Teltonika Ping Reboot: How to Keep a 4G or 5G Router Connected

Why does a cellular router need to reboot itself?

A fixed-line router normally sits behind a comparatively stable physical circuit. A cellular router lives in a much more dynamic world. The modem has to remain registered with a mobile network, maintain a packet-data session, deal with changing cells and radio conditions, keep an APN session alive and, with roaming or multi-network SIMs, sometimes negotiate with networks that are not the SIM’s home network.

Most of the time this works invisibly. Occasionally it does not. The awkward failure is not always “no signal”. A router may still show bars, a network name or registration while the useful data session has stopped passing traffic. In other words, the device looks connected from one layer while the application above it is effectively offline.

This is the cellular limbo problem. We discuss the wider connectivity issue in our Onomondo IoT connectivity article: keeping an IoT device connected over years is not simply a question of inserting a SIM and assuming the network state will remain perfect forever.

What Teltonika Ping/Wget Reboot actually does

RutOS can periodically send an ICMP ping or Wget request to a destination. If the destination does not answer, the router retries according to the rule you configure. Only after the failure condition is met does it take the selected recovery action.

On current RUTX50 firmware, Teltonika exposes several actions rather than only a full reboot: device reboot, modem reboot, restart mobile connection, re-register, send SMS, or no action. That matters because a failed mobile data session does not necessarily justify restarting the entire router.

Teltonika describes Auto Reboot as a precautionary mechanism for self-correcting unexpected issues, particularly connection downtime. The feature is therefore better thought of as a watchdog than a crude reboot timer.

The destination you ping matters more than people think

A ping watchdog is only as intelligent as the test behind it. If you configure the router to ping an address that cannot reliably answer ICMP, the router can interpret a perfectly healthy mobile connection as a failure and repeatedly reset itself.

Before using an IP address or hostname as the trigger for an automatic recovery action, confirm that the router can actually reach it through the interface you intend to monitor and that the destination normally responds to the type of test you have selected.

Current RutOS also supports multiple hosts for the active SIM and can be configured so the recovery action occurs only when all defined hosts fail. That is much safer than allowing the availability of one external server to decide whether a remote router should reboot.

IP address or hostname?

An IP address tests basic IP reachability without depending on DNS. A hostname deliberately tests more of the service chain because DNS must also work. Neither is universally better: choose the test that represents the failure you actually care about. Wget can go further and test whether a web endpoint is responding rather than merely whether a host answers ICMP.

A sensible Ping Reboot strategy

The dangerous configuration is an impatient one: one missed ping followed immediately by a full reboot. Mobile networks have brief interruptions. A cell handover, radio fade or transient upstream problem should not turn into a reboot loop.

The objective is not to make the router reboot frequently. A good watchdog should spend almost its entire life doing nothing.

Low-signal reconnect: a different problem

Ping Reboot asks: can I reach something? Low-signal reconnect asks: has my mobile signal fallen below the threshold for long enough that reconnecting may help?

On the RUTX50, RutOS provides a Low signal reconnect setting that can reset the modem’s operator connection when signal falls below a configured threshold, with a timeout controlling how soon it may try again.

This can be useful in moving deployments or marginal coverage, but it should not become a substitute for fixing a poor RF installation. If the router is permanently operating with weak or noisy signal, repeatedly reconnecting it treats the symptom rather than the cause. Our Teltonika Signal Optimisation guide explains how to examine RSRP, RSRQ, SINR, serving cells, bands and antenna placement first.

What about a daily scheduled reboot?

RutOS also includes a Reboot Scheduler. Unlike Ping Reboot, it does not wait for a fault: at the chosen day and time it reboots the device or modem regardless of whether the connection is healthy.

There is a legitimate argument for this in remote IoT. A quiet-hours reboot can periodically clear accumulated state and force a fresh mobile session before a problem develops. Teltonika itself describes scheduled rebooting as a prophylactic measure.

But it is not automatically best practice to reboot every router every night. A scheduled reboot creates guaranteed downtime and can hide an underlying network, firmware, configuration or RF problem. For an installation that is demonstrably stable, there is little virtue in interrupting it simply because the clock says 03:00.

SIM cards can be “connected” and still be in limbo

This is the reason these features exist. Cellular connectivity is a chain of states: the modem must see radio coverage, register on a permitted network, establish a data context through the APN, receive usable addressing and routing, and then reach the service the application needs.

A fault can occur between those layers. Looking at “4G” or “5G” on the status page tells you something useful, but it does not prove the entire chain is alive. The router’s watchdog closes that gap by asking a brutally simple question: can I still reach the outside world?

For a broader explanation of IoT SIM behaviour see What is an IoT SIM Card? and our Multi-Network SIM guide. Multi-network access can improve resilience, but it does not remove the need to monitor whether the end-to-end data path is actually working.

Dual-SIM routers: recovery can include changing SIM

On dual-SIM Teltonika models, recovery can go beyond resetting the existing session. RutOS SIM-switch logic can respond to conditions including weak signal, no network, network denied and data connection failure. For data connection failure, Teltonika supports LCP echo or ICMP echo health monitoring.

That gives you another resilience layer: if SIM 1 genuinely cannot establish a working path, the router may be able to move to SIM 2. This is especially valuable when the two SIMs use genuinely different connectivity arrangements rather than simply duplicating the same single point of failure.

However, the same principle applies: prove the failure before switching. A bad ping target can make an intelligent dual-SIM router behave very unintelligently.

Do not confuse a reboot with a factory reset

A reboot restarts the device. It does not deliberately erase your configuration. A factory reset is a completely different operation that returns the router to factory settings and can remove configuration and management information.

This distinction matters when documenting remote support procedures. “Reboot the router” should never become ambiguous shorthand for pressing and holding a reset button until something happens.

A practical configuration workflow

1. Prove the underlying cellular connection first. Check APN, registration, signal quality and normal internet/application reachability.
2. Choose what “healthy” means. Internet reachability, your VPN endpoint, application server or a combination.
3. Test the target manually from the router. Confirm it reliably answers Ping or Wget.
4. Force the test over mobile where appropriate. Do not accidentally monitor another WAN.
5. Use more than one target where practical. Avoid rebooting because one third-party host had a bad afternoon.
6. Allow retries and sensible timeouts. A transient packet loss is not a dead connection.
7. Choose the least disruptive recovery action. Mobile restart/re-register before escalating to modem or device reboot where that suits the fault.
8. Test the failure deliberately. In a controlled environment, remove/block the WAN and prove the rule behaves as expected.
9. Review logs after deployment. Frequent automatic recoveries are evidence to investigate, not proof that the problem is solved.

The bigger lesson: design recovery before the site is unattended

The best time to configure a watchdog is on the bench, not after the router has been installed on a roof, inside a roadside cabinet or 200 miles away.

Remote IoT equipment should be designed on the assumption that connectivity will eventually encounter an unusual state. That does not mean cellular is unreliable; it means resilient systems are built to detect faults and recover without waiting for a human being to drive to site.

Ping Reboot is deceptively simple, but used properly it is one of the most useful tools in an industrial cellular router. It turns “is the modem showing signal?” into the question that actually matters: is the service still reachable, and if not, what is the smallest action that gets it back?

Frequently asked questions

Related reading

Sources and notes: Teltonika Networks Wiki, current RUTX50 Maintenance documentation for Auto Reboot, Ping/Wget Reboot and Reboot Scheduler; RUTX50 Mobile documentation for Low signal reconnect and SIM-switch conditions; RUTX50 Internet Status and Device Recovery documentation. Menu names and available actions can vary by RutOS version and device family, so verify against the firmware and model being deployed. IoTPortal’s recommendations on watchdog design, target selection and recovery escalation are practical engineering guidance rather than Teltonika-prescribed universal settings.