Technical architecture
Two perspectives. Separate authority. Safer recovery.
RecoverNode separates observation from disruptive recovery so a broken monitoring path cannot automatically power-cycle a healthy server. The observer can compare named internal-reference and client-facing resolver paths, direct UDP and TCP DNS answers, and remaining TTLs to expose resolver divergence, split-horizon leakage, stale cached public answers, fallback inconsistencies, and path changes. The assessment separately evaluates effective merged Netplan state and contributing source declarations so stale or overridden settings can be identified as configuration drift rather than mistaken for active behavior. The guided installer detects the server role, supported watchdog controls, and Raspberry Pi power-health capability, then builds the required configuration without requiring manual JSON, systemd, or Nginx edits.
Download Technical Overview01RecoverNode Observer
Runs on a separate Ubuntu host and monitors multiple services.
- Local and public DNS expectations
- DNS Path Integrity across named internal-reference and client-facing resolvers, with UDP/TCP and TTL/cache-risk classification
- Effective Netplan and source-file drift classification
- HTTP status, redirects, latency, and content
- TLS chain, hostname, expiration, and certificate-specific alert cadence
- TCP services including application ports
- Multi-site observer/network and shared-DNS incident correlation
- Escalating alerts and persistent state
Evidence
not authority
02RecoverNode Guards
Run locally on protected hosts and make decisions from local evidence.
- Nginx-host, application-host, or combined-host role
- Local health and configuration validation
- Service-specific restart and retest behavior
- Exponential backoff, cooldown, and action budgets
- Persistent lockout after unsafe repetition
Decision model
Recovery stops when the system cannot make a sane decision.
Safe automatic recovery is not the same thing as auto-restart. RecoverNode treats recovery as a bounded decision made from local evidence, not as an unconditional response to a failed remote check.
Healthy locallyNo action
Nginx failed locallyValidate, restart, retest
Application failed locallyRecover the application service only
Persistent local failureApply cooldown and recovery budget
Ambiguous configurationFail open, lock out, alert
Observer cannot reach targetAlert only—no remote reboot
Multiple sites share network/DNS symptomsCorrelate into one infrastructure incident
Separate protection layers
Service recovery, DNS resilience, watchdog reset, and power reporting solve different problems.
RecoverNode keeps these functions separate so evidence from one layer does not silently authorize an unsafe action in another. DNS Path Integrity, DNS-resilience, and network-consistency findings produce diagnostic evidence and alerts; they do not automatically rewrite resolver, Netplan, or network configuration. When matching failures appear across multiple monitored sites, the observer can preserve each site's failure state while consolidating the notification into one infrastructure incident.
01Service recovery
Local guards validate and restart an unhealthy Nginx or application service within bounded action budgets.
02Operating-system watchdog
A supported hardware watchdog can reset a powered host after an operating system or userspace freeze.
03Raspberry Pi power health
Supported Raspberry Pi hosts can report current or historical undervoltage and throttling flags. RecoverNode records and alerts on the evidence but does not reboot a host whose power source may be unstable.
Power limitation: software and watchdog services cannot recover a device that lacks enough power to reach firmware, the bootloader, the operating system, or systemd.
