Building a Hardware Watchdog: How Dead Man's Internet Power-Cycles Your Router When the ISP Dies

Hook

Your internet went down at 3 AM and you didn't notice until your morning standup failed to connect. What if a $35 device could have power-cycled your frozen router while you slept?

Context

Internet service providers love to advertise 99.9% uptime, but anyone who's worked remotely knows the reality: routers freeze, modems hang, and connections mysteriously die until someone physically unplugs the device and plugs it back in. Software-based monitoring solutions can detect these failures, send alerts, even attempt graceful reconnections—but they all share a fatal flaw. When your router is truly frozen or your modem has locked up, no amount of software commands will help. You need someone (or something) to physically cut the power.

This is the gap that Dead Man's Internet fills. It's a hardware-based network watchdog built around an ESP32-S3 microcontroller that sits between your network equipment and its power source. When it detects connectivity failure through ICMP ping checks, it doesn't send a command or make an API call—it physically opens a relay to cut power, waits, then closes it again. It's the digital equivalent of having someone sit next to your router with instructions to unplug it whenever the internet dies. The project emerged from the frustration of managing remote systems that would go dark for hours until someone could physically access the equipment, a problem that costs remote workers, small businesses, and homelab enthusiasts countless hours of downtime.

Technical Insight

Dead Man's Internet runs on an M5Stack AtomS3, which packs an ESP32-S3 microcontroller, 0.85-inch LCD display, WiFi, and a compact form factor into a development board that costs around $15. The device connects to a 4-channel relay module that handles the actual power switching. The architecture is deceptively simple: boot up, connect to WiFi, start pinging a configurable target (default 8.8.8.8), and trigger the relay sequence if pings fail.

The core monitoring loop demonstrates the straightforward approach:

void checkConnection() {
  if (Ping.ping(targetIP.c_str(), 1)) {
    consecutiveFailures = 0;
    connectionStatus = "Connected";
    lastSuccessfulPing = millis();
  } else {
    consecutiveFailures++;
    if (consecutiveFailures >= FAILURE_THRESHOLD) {
      connectionStatus = "Failed - Cycling Power";
      powerCycleModem();
      consecutiveFailures = 0;
    }
  }
}

void powerCycleModem() {
  digitalWrite(RELAY_PIN, HIGH);  // Cut power
  delay(10000);                   // Wait 10 seconds
  digitalWrite(RELAY_PIN, LOW);   // Restore power
  delay(60000);                   // Wait 60 seconds for boot
  lastResetTime = millis();
  resetCount++;
}

What makes this more intelligent than a simple ping-then-reset loop is the consecutive failure threshold and recovery timing. The system doesn't panic on a single dropped packet—it waits for multiple consecutive failures before taking action. This prevents unnecessary power cycles during momentary network hiccups. The 60-second post-reset delay is equally important: modern routers and ONTs can take 30-45 seconds to fully boot and establish WAN connections. Resetting again too quickly would just compound the problem.

The firmware also includes an often-overlooked but critical safety feature: a watchdog timeout that reboots the ESP32 itself if it hasn't successfully pinged in 60 minutes. This solves the "who watches the watchman" problem. If the ESP32 loses WiFi connectivity, crashes, or enters a stuck state, it won't sit there indefinitely claiming everything is fine. After an hour of inability to verify connectivity, it assumes it's the problem and resets itself:

void loop() {
  unsigned long currentMillis = millis();
  
  // Self-watchdog: reboot if no successful ping in 60 minutes
  if (currentMillis - lastSuccessfulPing > 3600000) {
    ESP.restart();
  }
  
  if (currentMillis - lastCheck >= CHECK_INTERVAL) {
    checkConnection();
    lastCheck = currentMillis;
  }
  
  handleWebServer();
  updateDisplay();
}

The web interface runs on the ESP32's built-in web server capabilities, offering both an HTML dashboard and a JSON API. The API design is minimal but functional, providing endpoints for status checks and manual reset triggering. There's no authentication layer—the assumption is that this device lives on your internal network, not exposed to the internet. The mDNS responder allows you to access the interface via http://deadman.local rather than hunting for the IP address, a small UX detail that makes a difference when you're troubleshooting from your phone at 2 AM.

The display integration uses the M5Stack's built-in TFT screen to show real-time status: current connection state, uptime since last reset, the device's own IP address, and a visual indicator of the last ping result. This local feedback loop is invaluable when commissioning the device or debugging issues—you can see at a glance whether the device itself is functioning, separate from whether your internet is working.

Gotcha

The Achilles' heel of Dead Man's Internet is that it's a single-point-of-failure system masquerading as a reliability solution. If the ESP32 itself crashes hard enough that the watchdog timer doesn't trigger, or if it loses connection to your WiFi network (not the internet, just your local WiFi), it becomes blind and useless. You've now added another device to your network stack that can fail, and unlike your router, it doesn't have built-in redundancy or fallback mechanisms. The only recovery is manual power cycling of the watchdog itself—exactly the problem you were trying to solve.

The ping-based health checking is also more primitive than it might first appear. ICMP pings to 8.8.8.8 tell you that you can reach Google's DNS server, but they don't detect DNS resolution failures, asymmetric routing issues, or degraded connections where pings succeed but TCP connections time out. If your ISP starts doing transparent DNS hijacking, or if you're experiencing packet loss that's severe enough to break video calls but not severe enough to fail ping checks, this device will happily report that everything is fine while your Zoom meeting descends into chaos. There's also the security elephant in the room: the web interface has zero authentication. Anyone on your network can view status and trigger manual resets. If you've port-forwarded this device or put it in a DMV without firewall rules, you've created a remotely-triggerable kill switch for your own internet connection.

Verdict

Use Dead Man's Internet if you're managing remote systems (vacation home servers, remote office equipment, parents' houses), experience frequent ISP modem freezes that require physical power cycles, or run services from home where uptime matters and you can't justify enterprise equipment costs. It's particularly valuable when your connectivity issues manifest as complete hardware lockups rather than configuration problems—the scenarios where software solutions are powerless. The $35 build cost makes it a no-brainer experiment even if you're just curious about hardware-based network automation. Skip if your network equipment already has built-in watchdog capabilities, you need sophisticated health checks beyond simple ping monitoring, or you require security features like authenticated API access. Also skip if your ESP32 development experience is zero and you're not comfortable debugging embedded firmware issues—this is a DIY project, not a polished consumer product. Finally, skip if your primary connectivity issues are WiFi-related rather than WAN/modem problems; power-cycling your cable modem won't fix your router's 2.4GHz interference issues.