iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An ESP32 can reboot a separate server only when it has two things: a reliable way to decide that the server or its application is unhealthy, and an authorized control path that the server supports. The ESP32’s own watchdog is not that control path. It resets the ESP32 when the microcontroller becomes unresponsive; it does not switch another computer’s power.
The dependable design is a small state machine: keep the ESP32 powered independently, request a meaningful health endpoint at intervals, count consecutive failures, invoke the server’s supported management or power-recovery method after a deliberate threshold, then wait and verify recovery before allowing another action.
Understand the two different watchdog jobs
Espressif describes a watchdog timer as a mechanism that monitors system operation and restarts the chip when it becomes unresponsive. The ESP-IDF interrupt watchdog (IWDT) and task watchdog (TWDT) therefore protect the ESP32 itself. They can recover a stalled interrupt handler or task, but they have no authority over a separate server. See the ESP-IDF Watchdogs guide for the controller-side behavior.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11| Function | What it observes | What it can restart |
|---|---|---|
| ESP32 IWDT or TWDT | Interrupt and task execution on the ESP32 | The ESP32 |
| Server health checker | An application or service response, with network conditions included | Nothing by itself; it only decides when recovery should be requested |
| Server management or power-control path | A command, management event, or electrical control input accepted by the server setup | The target server, if the interface is compatible and authorized |
This separation prevents a common failure: configuring a more aggressive ESP32 watchdog and expecting it to repair a remote computer. A stalled ESP32 would simply reboot the monitor while the server remained untouched.
#1 Best Overall
- 2.4GHz Dual Mode WiFi + Bluetooth Development Board
- Support LWIP protocol, Freertos
- SupportThree Modes: AP, STA, and AP+STA
- Ultra-Low power consumption, Compatible with Arduino IDE
- ESP32 is a safe, reliable, and scalable to a variety of applications
Choose how the server will recover
Before writing firmware, identify the server’s actual recovery interface. The ESP32 should issue the least disruptive action that the server supports.
| Recovery method | Advantages | Constraints to verify |
|---|---|---|
| Server management interface | Can request an orderly reboot or power action without cutting unrelated equipment; often provides a result or audit event. | The exact server model, management firmware, credentials, network reachability, and command semantics must support remote recovery. |
| Supported remote power control | Can recover a machine whose operating system is completely hung, provided the power-control system is independent. | Must match the server’s input and electrical requirements; a generic relay is not automatically compatible. A power cut can corrupt data and can interrupt other loads. |
| Local physical control input | May emulate a supported power or reset button when the server provides one. | Requires the correct isolation, polarity, pulse duration, and connector. The server documentation must define the interface. |
Do not select a relay, solid-state switch, or mains wiring from the ESP32 board alone. The server’s voltage, current, inrush, grounding, isolation, enclosure, and applicable electrical rules determine suitable hardware. If the target is mains-powered, have a qualified person design and inspect the installation. Keep the controller’s low-voltage supply and network operation independent of the server’s power so the monitor remains alive while the target is off.
Define “stopped responding” with a real health check
A ping or successful TCP connection proves only that some network layer answered. It does not prove that the application is accepting work, that its dependencies are usable, or that a load balancer sent the request to a healthy instance. Prefer a small HTTP endpoint that represents the service the reader actually needs. The endpoint might return success only after its critical dependencies are ready and should have a documented response contract.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →ESPHome’s HTTP Request component supports GET requests, response status handling, and request-duration information. Use those results to classify each probe as healthy, unhealthy, or inconclusive. For example, an HTTP response with the expected status and body can be healthy; a timeout, DNS failure, connection refusal, TLS failure, unexpected status, or explicitly unhealthy body can be a failure. A response that indicates a dependency is still starting should be treated according to the endpoint’s contract rather than guessed from the transport result.
Make the endpoint cheap and side-effect-free. A health check should not create a job, mutate data, or trigger a login flow that can itself lock the service. Bind it to the intended local interface or protect it with authentication appropriate for the deployment. If the endpoint is unavailable, record whether the failure occurred during name resolution, connection, TLS negotiation, or reading the response; those distinctions help prevent a network outage from being mistaken for a server crash.
Rank #2
- Dual-Core Performance Up to 240 MHz: Run sensor processing, wireless communication, automation logic and connected-device tasks on a 32-bit dual-core ESP32 platform designed for responsive embedded and IoT projects
- Built-in Wi-Fi and Bluetooth 4.2: Connect to 2.4 GHz Wi-Fi networks or use Bluetooth Classic and BLE for wireless sensors, smart devices, remote controls, home automation and other connected projects
- Flexible Power-Saving Modes: ESP32 power-management features support dynamic clock scaling and low-power operating modes, helping developers reduce energy use in compatible sensing, monitoring and connected-device applications, suitable for battery-powered Internet of Things (IoT) devices.
- USB-C Programming with CP2102: Connect through USB-C for power, sketch uploads and serial monitoring, while GPIO, UART, SPI and I2C interfaces support sensors, displays, motor drivers and other modules (USB-C cable not included)
- Over-the-Air Update Support: Configure OTA functionality through a compatible ESP-32 software framework to update deployed firmware over Wi-Fi without reconnecting the board by USB for every revision
Account for request timeouts and HTTPS security
ESPHome documents a default HTTP-request timeout of 4.5 seconds. On ESP32, that timeout applies separately to network operations such as DNS lookup, connection establishment, TLS handshake, and reads or writes; it is not necessarily one whole-request deadline. Set a finite timeout that fits the service’s normal latency and your failure-detection goal, then test it under the slowest expected network conditions.
Keep certificate verification enabled. ESPHome enables verification by default on supported ESP32 builds and warns that disabling it can expose HTTPS traffic to person-in-the-middle attacks. If the server uses a private or self-signed certificate, configure the documented CA-certificate option for the appropriate trust chain instead of making verify_ssl: false a routine workaround. A certificate that is expired, issued for another name, or signed by an untrusted authority should be fixed or deliberately trusted through a controlled CA configuration.
Recommended Free Tools
HTTP requests run on ESPHome’s main loop. The component’s watchdog_timeout option changes the watchdog timeout during connection and data transfer; the documentation cautions against increasing it without observing watchdog-related reboots, because a larger value can delay recovery from a genuine ESP32 fault. First reduce endpoint latency, correct DNS or TLS problems, and use a sensible request timeout. Change the watchdog setting only when measurements show that the transfer itself is the cause.
Build the failure-and-recovery state machine
Thresholds are deployment decisions, not universal values. A practical controller avoids acting on one transient packet loss and avoids an endless reboot loop.
- Start in a known state. Set the consecutive-failure count to zero, mark the target as unconfirmed, and record the time of the last recovery action. Do not permit an action until the ESP32 has a usable network connection and the configured recovery lockout has elapsed.
- Probe periodically. Send the health request at a fixed interval. Keep the interval long enough for the service to respond and for the network to settle; do not launch overlapping requests.
- Classify the result. Reset the failure count on a valid healthy response. Increment it for a timeout, connection or DNS error, TLS validation error, unexpected status, or unhealthy response, according to the endpoint’s documented contract. Store the status and duration for diagnosis.
- Require consecutive failures. Trigger recovery only after a deliberate number of failures in a row. A counter is usually safer than a percentage over a moving window because it is easy to explain and audit. Choose the number and probe interval from the application’s tolerance for downtime and the cost of a false reboot.
- Issue one compatible recovery action. Call the server’s supported management command or the correctly engineered power-control interface. Treat a command acknowledgement as evidence that the action was accepted, not as proof that the operating system recovered.
- Enter a recovery lockout. Wait for the server’s expected boot and service-start time. During this period, suppress additional actions and continue recording observations. If the target has a documented boot-complete signal, use it; otherwise rely on repeated health checks after the interval.
- Verify and escalate carefully. A healthy response clears the failure state. If the service is still unhealthy, permit another action only after a longer, explicit lockout and a bounded retry policy. After the retry limit, enter an alarm state instead of cycling power indefinitely.
A language-neutral implementation looks like this:
every probe_interval:result = request_health_endpoint(timeout)log(result.status, result.duration, result.error)if result.is_healthy:consecutive_failures = 0target_state = 'healthy'else:consecutive_failures += 1if consecutive_failures >= failure_threshold:if recovery_lockout_expired and retries < retry_limit:invoke_authorized_recovery()retries += 1start_recovery_lockout()else:target_state = 'needs_attention'
The names above are logic, not a drop-in ESPHome schema. Map them to the version of ESPHome or ESP-IDF you use, and keep the action that controls the server separate from the ESP32’s own reset action.
Rank #3
- Powerful ESP-32 Board: Unlock the world of Internet of Things (IoT) and advanced electronics with the heart of this kit: the ESP-32 board. It features a powerful dual-core processor, integrated Wi-Fi and Bluetooth 4.2, making it perfect for building connected, smart devices that communicate with your phone or the cloud. It's fully compatible with the Arduino IDE for easy programming.
- Super Starter Kit: This kit contains over 35 different modules and electronic components, including sensors, displays, motors, and input devices. From LEDs and buttons to an OLED screen, servo motor, and keypad, you have everything needed to explore a vast range of projects in one box.
- Step by Step Online Tutorial: Jump right in with our detailed, beginner-friendly tutorial. Access 30+ projects with complete code, clear circuit diagrams, and step-by-step instructions. Learn the fundamentals of electronics, coding, and how to utilize the ESP-32's unique capabilities without any prior experience.
- Hands-on Learning for All Skill Levels: Perfect for students, makers, engineers, and hobbyists. Start with basic circuits and coding, then progress to intermediate and advanced IoT applications. Build practical projects like weather stations, smart home controllers, remote-controlled devices, and interactive gadgets. The skills you learn are the foundation for real-world innovation.
- Quality & Great Support: Elegoo is committed to quality. We provide a clear, detailed tutorial guide, refined code, and a well-organized component kit. All modules are carefully selected for reliability and ease of use. Our dedicated technical support team and active online community are ready to help you succeed in your learning journey.
Implement it with ESPHome
Configure the HTTP request component
Add the HTTP Request component with a finite timeout, the intended user agent, and certificate verification. The component documentation describes the GET action, response capture, status information, and duration data. Use the current syntax in the version you have installed; action and trigger details are documented in ESPHome Actions, Triggers, and Conditions.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhen the endpoint is HTTPS, install or reference the CA certificate required by your server’s trust chain. Do not hide certificate failures by turning verification off. If your service is available only by a stable local address, use a DNS name whose certificate matches that name, or use a properly managed local CA.
Run the check locally on the controller
Use an ESPHome interval automation or an equivalent local automation to perform the probe and update the counter. ESPHome automations execute on the microcontroller and continue operating when Wi-Fi is down or MQTT is unreachable. That makes local decision-making preferable to a cloud or broker rule for the actual safety threshold. A failed request still cannot identify the cause by itself, so include the network state and error category in the log.
ESPHome also has API connectivity and reboot-timeout behavior for the ESPHome device. That behavior protects the controller’s own connectivity; it is not evidence that the monitored server or application is down. Keep those settings conceptually separate from the health-check counter and server-recovery action.
Connect the recovery action only after compatibility testing
For a management interface, place the authenticated request or command behind the server’s documented authorization boundary and test it without the failure trigger first. Confirm that one command produces exactly one intended action and that the response can be logged.
Rank #4
- 2.4GHz Dual Mode WiFi + Bluetooth Development Board
- Support LWIP protocol, Freertos;ESP32 is a safe, reliable, and scalable to a variety of applications
- SupportThree Modes: AP, STA, and AP+STA
- Ultra-Low power consumption, Compatible with Arduino IDE
- 1PCS 30Pin ESP32 Development Board 2.4GHz WiFi Dual Cores Microcontroller Integrated with Antenna RF Low Noise Amplifiers Filters
For a power or physical-control path, use hardware selected for the server’s exact electrical and mechanical interface. Add isolation, flyback protection, fusing, and enclosure provisions where the design requires them; do not connect an unknown load directly to an ESP32 GPIO. The ESP32 should not be the sole safety mechanism for equipment that could create a hazard.
Keep the network path dependable
Use a stable local network and reserve a predictable address or name for the target. Separate DNS failures from server failures in logs. If a wired link is preferable, ESPHome supports Ethernet, but the configuration depends on the controller, PHY, interface, and framework. Its Ethernet component documentation warns that SPI Ethernet uses a high-frequency clock; flying leads or Dupont wires can therefore be unreliable. Use the wiring and layout appropriate for the selected board and PHY rather than assuming any jumper arrangement will work.
Consider a second observation path when false positives are costly. For example, a service endpoint can be the primary test while link state, DNS resolution, and a separate management response are recorded as diagnostics. Do not count every diagnostic failure as a reason to power-cycle unless the policy explicitly says that the network itself is the fault domain you want to recover.
Prevent false positives and reboot loops
- Use consecutive failures, not one miss. A single lost packet, brief Wi-Fi roam, or busy application should not immediately interrupt a server.
- Use a recovery lockout. Give the machine time to boot, mount storage, start services, and become ready before judging the action.
- Cap automatic retries. After a small, defined number of actions, stop and raise an alert. Endless cycling can damage data and hide a persistent configuration or hardware problem.
- Keep evidence. Log timestamps, endpoint status, duration, error category, failure count, action result, and post-action checks. Retain enough history to distinguish an application regression from a network outage.
- Make the action idempotent where possible. A repeated management request should not queue multiple conflicting operations. If the interface is not idempotent, enforce a longer lockout and a single in-flight action.
- Protect the control path. Restrict credentials, limit the management endpoint to the controller’s network, and avoid putting power-control commands on an unauthenticated HTTP endpoint.
Test the complete chain before enabling automatic recovery
- Verify that the ESP32 remains powered when the server is switched off.
- Call the health endpoint manually and confirm its healthy and unhealthy responses are unambiguous.
- Test DNS, TCP, TLS, and response-read failures separately where practical, and confirm that each is logged with the expected category.
- Temporarily replace the real recovery command with a harmless indicator, such as a log event, to validate the consecutive-failure threshold and lockout timing.
- Invoke the authorized server recovery method manually and verify that it affects only the intended server.
- Simulate a hung application while leaving the host reachable, then simulate a powered-off host. Confirm that the endpoint check detects both conditions without treating a normal slow response as a crash.
- Interrupt the controller’s Wi-Fi or MQTT connection and verify that local automation continues without issuing an unsafe action based solely on broker availability.
- After a real recovery, verify the health endpoint repeatedly and confirm that the failure counter clears only after the service is genuinely ready.
Diagnose common failure modes
The ESP32 keeps rebooting instead of the server
Inspect the ESP32’s IWDT or TWDT logs and the HTTP request timing. A blocked callback, malformed automation, or transfer that exceeds the controller watchdog can reset the monitor. Do not interpret that reset as a server-recovery event. Fix the controller fault first, and only consider the HTTP component’s watchdog_timeout adjustment after confirming the documented watchdog symptom.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →The endpoint reports failure although the server is healthy
Check DNS, route selection, firewall rules, TLS hostname and certificate chain, and the endpoint’s readiness criteria. Compare the ESP32’s recorded duration with the configured timeout. If the service occasionally exceeds the limit during normal load, tune the endpoint or probe policy rather than using an unlimited request.
Best Value
- 2.4GHz Dual Mode WiFi + Bluetooth Development Board
- Ultra-Low power consumption, works perfectly with the Arduino IDE
- Support LWIP protocol, Freertos
- SupportThree Modes: AP, STA, and AP+STA
- ESP32 is a safe, reliable, and scalable to a variety of applications
The server is reachable but the application is broken
Replace a ping-only test with an application-level endpoint. Ensure the endpoint checks the dependencies that matter to users, while avoiding expensive work that makes the health check itself a load source.
The server never recovers after the action
Verify the management command’s authorization, the physical control interface, and the target’s boot behavior independently. Check whether the power-control device is actually independent of the server’s supply and whether a breaker, UPS, or interlock prevents the requested state change. The ESP32 cannot compensate for an incompatible or unsafe control circuit.
The controller enters ESPHome safe mode
Safe mode addresses repeated ESPHome boot failures, not a failed target server. ESPHome documents a default of ten failed boots before safe mode may be invoked; in safe mode, networking and OTA remain available while most components are disabled. See the ESPHome Safe Mode documentation when recovering the controller, but do not use safe mode as the server-reboot mechanism.
Know what this design can and cannot guarantee
This arrangement can automate a bounded recovery attempt when a defined service condition persists and the control interface is available. It cannot prove the root cause from one failed request, guarantee that a power cycle repairs corrupted software or hardware, or make an unsupported server interface safe. There is no universal failure threshold, timeout, relay, or wiring diagram that fits every server. Select those details from the service’s tolerance, the server’s documented management and electrical interfaces, and the consequences of an incorrect reboot.
The essential design rule is simple: let the ESP32 watchdog protect the ESP32, let a measured health check decide whether the target service is unhealthy, and let a separately validated management or power-control path perform one controlled recovery. Independent power, certificate validation, explicit thresholds, recovery lockouts, and useful logs turn that rule into a system that can be tested and trusted.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
