What is Ping Reboot?

Ping reboot — also known as ICMP watchdog, ping watchdog, or auto reboot on connectivity loss — is an automatic recovery mechanism built into most industrial cellular routers. It continuously monitors internet connectivity by sending ICMP ping packets to a target host and, when it detects a sustained loss of connectivity, automatically reboots the router to restore the connection.

For anyone deploying cellular routers in remote or unmanned locations — whether that’s a CCTV system on a construction site, a building management controller in a plant room, or an energy monitoring gateway on a wind farm — ping reboot is one of the most critical features to configure correctly. Without it, a router that loses its cellular connection will stay offline until someone physically visits the site to power-cycle it.

This guide explains exactly how ping reboot works, why it’s essential for IoT deployments, and how to configure it properly.

How Ping Reboot Works

The principle behind ping reboot is straightforward. The router runs a background process — sometimes called a watchdog daemon — that periodically sends an ICMP echo request (a “ping”) to a configured target host. If the host responds, the router knows it has a working internet connection and resets its failure counter. If the host doesn’t respond within a set timeout period, the router increments a failure counter.

Once the failure counter exceeds a configured threshold — typically three to five consecutive failed pings — the router assumes the internet connection has been lost and performs an automatic reboot. After rebooting, the router re-establishes its cellular connection, re-negotiates with the network, and in most cases comes back online within two to three minutes.

Here’s the step-by-step sequence:

1. Router sends ICMP ping to the configured target host (e.g. 8.8.8.8)
2. Waits for a response within the configured timeout period (typically 5–10 seconds)
3. Response received: failure counter resets to zero, cycle repeats after the configured interval
4. No response: failure counter increments by one
5. Threshold exceeded: router triggers an automatic reboot
6. Router reboots, re-establishes the cellular and WAN connection
7. Monitoring resumes — the ping cycle begins again from step 1

The entire process is automatic and requires no human intervention, which is precisely the point. In a well-configured deployment, a router can recover from a cellular drop-out in under five minutes without anyone needing to visit the site.

Why Ping Reboot is Essential for IoT

Cellular connections are not permanent circuits. They rely on radio signals, network registration, IP address allocation from the mobile operator, and a chain of infrastructure between the device and the internet. Any link in that chain can fail — and when it does, the router’s modem can enter a state where it believes it still has a connection but is actually unable to pass traffic.

This condition — sometimes called a “silent failure” or “zombie connection” — is the primary reason ping reboot exists. The router’s status LEDs might show a connected state, the management interface might report a valid IP address, but no data is actually flowing. Without an active monitoring mechanism like ping reboot, the router will remain in this broken state indefinitely.

In unmanned IoT deployments, this creates a serious problem. The downstream equipment — CCTV cameras, environmental sensors, building controllers, SCADA systems — is functioning perfectly but cannot send its data anywhere. Depending on the application, this could mean missing security footage, lost telemetry data, failed alarm notifications, or breached SLA commitments.

The cost of a single truck roll to power-cycle a remote router typically ranges from £80 to £300, depending on distance and urgency. For deployments with hundreds or thousands of routers, manual recovery is simply not viable. Ping reboot eliminates the vast majority of these site visits.

When Do You Need Ping Reboot?

Ping reboot should be enabled on virtually every cellular router deployment where the router is not easily accessible for manual intervention. Specific scenarios where it’s particularly critical include:

Remote and unmanned sites — construction sites, agricultural installations, temporary event connectivity, remote CCTV, environmental monitoring stations, and any location where the router is installed in a locked cabinet, on a mast, or in a location that requires a site visit to access.

Business-critical connectivity — point-of-sale systems, ATMs, digital signage, access control systems, and any application where downtime directly impacts revenue or safety. In these environments, ping reboot is typically combined with dual-SIM failover for maximum resilience.

Industrial IoT and M2M — SCADA systems, energy metering, water and gas telemetry, building management systems, and smart grid infrastructure. These deployments often run for years on a single configuration, and the router needs to self-recover without intervention.

Multi-site fleet deployments — when you’re managing dozens or hundreds of routers across different locations, manual recovery doesn’t scale. Ping reboot is a fundamental part of any fleet management strategy.

The only scenarios where ping reboot might not be needed are desktop or office environments where someone is physically present and can manually restart the router, or in wired (non-cellular) deployments where the failure modes are different.

Ping Reboot vs Periodic Reboot

Routers typically offer two types of automatic reboot: ping reboot and periodic (scheduled) reboot. They serve different purposes and are often used together.

Ping reboot is event-driven. It only triggers when the router detects an actual connectivity failure. If the connection is working perfectly, the router never reboots. This makes it a reactive measure — it responds to a problem when one occurs.

Periodic reboot is time-driven. The router reboots on a fixed schedule — for example, every night at 3am, or once a week on a Sunday. This is a preventive measure designed to clear memory leaks, refresh the cellular registration, and reset any software state that may have degraded over time.

For most IoT deployments, the recommended approach is to use both: a periodic reboot scheduled for a quiet time (such as 03:00 on a Sunday) to keep the router in a fresh state, combined with ping reboot to catch any unexpected connectivity failures between scheduled reboots.

Periodic reboot alone is not sufficient because a connectivity failure can happen at any time — not just before the next scheduled reboot. If the router drops its connection at 9am on a Monday and the next periodic reboot isn’t until 3am on Sunday, you’ve lost nearly a week of connectivity.

Ping reboot alone is usually sufficient for connectivity recovery, but periodic rebooting can help prevent some of the conditions that cause connectivity failures in the first place, particularly on older firmware versions or during extended deployments.

Configuring Ping Reboot: Key Parameters

Every router implements ping reboot slightly differently, but the core parameters are consistent across most manufacturers. Here are the settings you’ll need to configure:

Ping Target (Host)

This is the IP address or hostname that the router will ping to verify connectivity. Common choices include:

• 8.8.8.8 — Google’s public DNS. Highly reliable and globally routable, but some mobile operators filter ICMP traffic to this address.
• 1.1.1.1 — Cloudflare’s public DNS. An alternative to Google’s DNS.
• Your own server — if you have a static IP server or cloud instance, pinging your own infrastructure gives you the most accurate view of whether your specific traffic path is working.

Important: If your SIM card uses a private (non-routable) IP address — which is common with many IoT SIM providers — you cannot ping public internet hosts like 8.8.8.8. You’ll need to ping an address within the operator’s network, or use a host that’s reachable via the private APN. See our explainer on private IoT SIM cards for more detail.

It’s good practice to configure two ping targets if your router supports it. This prevents a reboot being triggered by a temporary issue with a single target host rather than an actual connectivity failure on the router.

Ping Interval

How frequently the router sends a ping, typically measured in seconds. Common settings range from 60 seconds to 600 seconds (10 minutes).

Recommended setting: 300 seconds (5 minutes) for most deployments. This provides a good balance between detection speed and avoiding unnecessary reboots from brief network fluctuations.

Setting the interval too low (e.g. 30 seconds) can cause false positives during normal cellular handovers or brief network congestion. Setting it too high (e.g. 30 minutes) means the router could be offline for an hour or more before it detects the problem and reboots.

Failure Count (Retry Threshold)

The number of consecutive failed pings required before triggering a reboot. This prevents a single missed ping from causing an unnecessary reboot.

Recommended setting: 3 consecutive failures for most deployments. Combined with a 300-second interval, this means the router will reboot after approximately 15 minutes of sustained connectivity loss — long enough to ride out a brief network outage, short enough to recover promptly from a genuine failure.

Ping Timeout

How long the router waits for a response to each individual ping before considering it failed, typically 5 to 10 seconds.

Recommended setting: 5 seconds. If a ping response takes longer than 5 seconds, the connection is effectively unusable for most IoT applications anyway.

Reboot Delay

Some routers offer a delay between deciding to reboot and actually executing the reboot. This can be useful if you need to log the event or gracefully disconnect clients before the restart.

Recommended setting: Use the default unless you have a specific reason to change it.

Recommended Settings Summary

For a standard industrial IoT deployment, these settings will provide reliable automatic recovery without false positives:

Parameter	Recommended Value	Notes
Ping Target	8.8.8.8 (public IP SIM)	Use operator gateway for private IP SIMs
Secondary Target	1.1.1.1	If router supports multiple targets
Ping Interval	300 seconds	5 minutes between pings
Failure Count	3	Reboot after 3 consecutive failures
Ping Timeout	5 seconds	Per-ping response timeout
Action	Device Reboot	Not just modem restart

With these settings, the worst-case detection-to-recovery time is approximately 20 minutes: 15 minutes to detect the failure (3 × 5-minute intervals) plus 2–5 minutes for the router to reboot and re-establish its cellular connection.

Common Mistakes

Pinging 8.8.8.8 on a Private IP SIM

This is the single most common configuration error. Many IoT SIM cards — particularly those from specialist IoT connectivity providers — use private (RFC 1918) IP addresses that do not have direct access to the public internet. The SIM is designed to connect to a specific VPN or private APN, not to browse the web.

On these SIMs, pinging 8.8.8.8 will always fail because the traffic cannot route to the public internet. The router will see 100% ping failure and reboot in an endless loop — rebooting every 15–20 minutes for the life of the deployment.

If you’re using a private IP SIM, you need to identify a host that’s reachable from within the operator’s private network and use that as your ping target. Your SIM provider should be able to advise on a suitable address.

Setting the Interval Too Low

An interval of 30 seconds or less will cause the router to be overly sensitive to brief network fluctuations. Cellular networks regularly experience momentary packet loss during cell handovers, congestion events, or network maintenance. A well-configured ping reboot should ride out these transient events, not react to them.

Using Only Modem Restart Instead of Full Reboot

Some routers offer both “modem restart” and “device reboot” as the action to take when ping reboot triggers. Modem restart only power-cycles the cellular modem — it doesn’t restart the router’s operating system, clear memory, or reset routing tables.

For most connectivity failures, a full device reboot is more effective because it clears all state and starts fresh. Unless you have a specific reason to prefer modem-only restart (such as maintaining a local LAN during recovery), always choose full device reboot.

Not Testing After Configuration

After enabling ping reboot, test it. The simplest method: temporarily change the ping target to an address you know doesn’t exist (e.g. 192.168.254.254), wait for the failure threshold to be exceeded, and confirm the router reboots automatically. Then change the target back to the correct address.

This takes 15–20 minutes but confirms that your configuration is actually working — something you definitely want to know before the router is installed at the top of a mast on a remote site.

Ping Reboot on Private IoT SIM Cards

Private IP SIM cards are increasingly common in IoT deployments because they offer better security than public IP SIMs — the device isn’t directly addressable from the internet, reducing the attack surface. However, they require special consideration when configuring ping reboot.

On a private IP SIM, the device is assigned an IP address from a private range (typically 10.x.x.x or 172.16.x.x). Traffic is routed through the operator’s private network to your corporate VPN or cloud platform, but the device itself cannot reach the public internet.

This means you cannot use standard public ping targets like 8.8.8.8 or 1.1.1.1. Instead, you need to:

1. Ask your SIM provider for a pingable gateway address within their private network
2. Use your own server’s private IP if your VPN endpoint is reachable from the SIM’s network
3. Use the SIM provider’s DNS server as a ping target — these are almost always reachable from within the private APN

If none of these options are available, some routers support using a wget (HTTP) check instead of ICMP ping. This can connect to your own application server’s URL, which may be reachable even when ICMP is filtered.

We have a dedicated explainer on private IoT SIM cards that covers this topic in more depth.

How Ping Reboot Fits Into a Reliability Strategy

Ping reboot is one layer of a multi-layered approach to ensuring reliable connectivity in industrial IoT deployments. A comprehensive reliability strategy typically includes:

Dual-SIM failover — the router carries two SIM cards from different mobile operators. If the primary SIM loses connectivity, the router switches to the secondary SIM. This handles operator-level outages that a simple reboot wouldn’t fix.

Ping reboot — catches silent failures and modem lock-ups that dual-SIM failover alone won’t detect (because the router thinks it’s still connected).

Periodic reboot — preventive maintenance reboot on a weekly or nightly schedule to keep the router in a clean state and prevent memory leaks or software degradation.

Remote management — platforms like Teltonika RMS or similar allow you to monitor router status, push configuration changes, and trigger manual reboots remotely across your entire fleet.

Quality antenna systems — a properly specified external antenna with low-loss cable dramatically improves signal quality and reduces the frequency of connection drops in the first place. Prevention is always better than recovery.

Correct SIM configuration — ensuring the APN, authentication, and network registration settings are correct for your specific SIM card and operator eliminates a whole class of connectivity issues.

When all of these layers work together, uptime figures of 99.5% to 99.9% are achievable even in challenging RF environments. Ping reboot is the safety net that catches the failures that everything else misses.

Router-Specific Ping Reboot Guides

We’ve created detailed, step-by-step configuration guides for the most popular industrial routers. Each guide includes screenshots, recommended settings, and a video walkthrough:

• Teltonika RUTX50 — 5G flagship router ping reboot configuration
• Teltonika RUTX11 — 4G CAT6 dual-band router ping reboot setup
• Teltonika RUT360 — Industrial 4G CAT6 DIN-rail router
• Teltonika RUT241 — Compact 4G CAT4 router
• Teltonika RUT200 — Entry-level 4G CAT4 router

More guides are being added regularly. If you need a guide for a specific router model, get in touch and we’ll prioritise it.

Frequently Asked Questions

Will ping reboot fix all connectivity issues?

No. Ping reboot fixes issues caused by the router’s modem or software entering a failed state — which is the most common type of connectivity failure. It won’t fix problems caused by a SIM card being deactivated, an operator network outage in your area, a faulty antenna connection, or incorrect APN settings. For operator-level issues, dual-SIM failover is the appropriate solution.

How often will my router reboot?

On a well-configured deployment with good signal strength and a correctly provisioned SIM card, ping reboot should rarely trigger — perhaps once or twice a month, or even less. If your router is rebooting frequently (daily or more), that indicates an underlying issue that needs investigating: poor signal quality, an incorrect ping target, or a SIM configuration problem.

Does ping reboot interrupt my local LAN?

Yes. A full device reboot will briefly interrupt any local LAN, Wi-Fi, and VPN connections — typically for 2–3 minutes. For deployments where LAN continuity is critical during WAN recovery, some routers offer a “modem restart only” option that keeps the local network running while only restarting the cellular modem.

Can I use a hostname instead of an IP address for the ping target?

Some routers support this, but it’s generally not recommended. If your DNS resolution depends on the same cellular connection that’s being tested, a DNS failure could prevent the hostname from resolving — masking the real connectivity test. Use IP addresses for ping reboot targets.

What’s the difference between ping reboot and a hardware watchdog?

A hardware watchdog is a separate timer circuit on the router’s circuit board that monitors whether the operating system is running. If the OS crashes or hangs completely, the hardware watchdog triggers a hard reboot at the hardware level. Ping reboot, by contrast, is a software function that runs within the OS and monitors internet connectivity. Both serve different purposes and operate at different levels — the hardware watchdog catches OS-level failures, while ping reboot catches network-level failures.

---

Last updated: February 2026. This guide is maintained by the PingReboot.co.uk team, drawing on 25+ years of experience deploying cellular IoT connectivity solutions across the UK.