​
Overview

Watchman Tower’s server agent, wt-warden, is a lightweight Go-based host agent that sends server health and runtime telemetry to the platform. Today, it is best understood as a practical server visibility layer for:
  • CPU usage
  • memory usage
  • disk usage
  • network transfer
  • load averages
  • uptime
  • swap usage
  • top resource-consuming processes
  • basic service health
  • local port health
  • selected runtime checks for common infrastructure services
  • Nginx virtual host discovery
The current server agent is production-usable and already goes beyond raw host metrics, but it is still intentionally focused. Docs should reflect what it does well today without implying full autodiscovery or deep observability.

​
How It Fits Into Watchman Tower

The server agent complements Watchman Tower’s broader monitoring workflow by adding host-side telemetry and local runtime context. That means teams can combine:
  • external uptime and status checks
  • domain and SSL visibility
  • internal WordPress signals when needed
  • server-side telemetry from wt-warden
  • service and runtime health from the host itself

​
Current Delivery Model

The current agent:
  • runs as a standalone Go binary named wt-warden
  • collects metrics directly from the host
  • sends metrics to Watchman Tower over HTTPS
  • uses a server-specific API key
  • follows the interval returned by the Watchman Tower API
  • can be installed with a one-line installer or run manually
  • can migrate older wt-monitoring installs to wt-warden

​
What the Platform Stores Today

On the backend side, Watchman Tower currently stores and surfaces:
  • the latest agent version reported by the server
  • current server status snapshots through Redis-backed cached data
  • recent server stat entries for historical views
  • process samples including PID information
  • service health, port health, and runtime health snapshots
  • discovered Nginx virtual host metadata
  • alerting structures tied to server resources

​
Current Runtime Signals

Depending on what is installed on the server, the current agent can also report:
  • service health for components such as Nginx, Docker, MongoDB, and Redis
  • listening state for important local ports
  • lightweight runtime summaries for Docker, Nginx, MongoDB, and Redis
  • discovered Nginx server_name, root, config path, and listen ports when Nginx configuration is readable

​
Current Limitations

This docs section intentionally reflects the current implementation and should stay precise. The current agent does not claim support for:
  • custom user-defined metrics
  • full automatic service inventory across arbitrary stacks
  • deep application tracing
  • container-level observability beyond the current Docker summary
  • guaranteed Nginx config discovery on every host configuration
  • Noema-based server interpretation today

​
Next Steps