​
Before You Start

The current server agent is distributed as wt-warden, a Go binary that sends server health and runtime metrics to Watchman Tower. To run it, you need:
  • a server entry created in Watchman Tower
  • the server’s server_id
  • the server’s api_key
  • the API URL used for metric ingestion
  • a Linux server with systemd
The recommended path is now the one-line installer. Manual installation still works and remains useful if you want full control over the binary or service file.
The easiest way to install wt-warden is with the hosted installer: 
curl -fsSL "https://downloads.watchmantower.com/wt-warden/install.sh" | sudo bash -s -- \
  --server-id="<your_server_id>" \
  --api-key="<your_api_key>" \
  --api-url="https://metric.watchmantower.com" \
  --version="v1.4.0"
This installer:
  • downloads the correct Linux binary for the server architecture
  • writes /etc/watchmantower/warden.env
  • creates wt-warden.service
  • enables and starts the service automatically
If you already run an older Watchman Tower server agent, use the upgrade script: 
curl -fsSL "https://downloads.watchmantower.com/wt-warden/upgrade.sh" | sudo bash -s -- \
  --server-id="<your_server_id>" \
  --api-key="<your_api_key>" \
  --api-url="https://metric.watchmantower.com" \
  --version="v1.4.0"
This upgrade flow is designed to:
  • migrate older wt-monitoring installs to wt-warden
  • rewrite the systemd service safely
  • preserve or migrate the existing runtime credentials
  • restart the agent on the new binary name

​
Required Flags

If you run the binary directly, the current agent accepts these flags: 
-server_id
-api_key
-api_url
The binary will not start correctly without server_id, api_key, and api_url.

​
Manual Run Command

If you want to run the agent directly: 
./wt-warden \
  -server_id="<your_server_id>" \
  -api_key="<your_api_key>" \
  -api_url="<your_api_url>"

​
Runtime Behavior

When the agent starts:
  1. it sends an initial payload containing static host information
  2. Watchman Tower returns an interval value
  3. the agent begins sending dynamic metrics on that interval
If the API does not return a usable interval, the agent falls back to a short default interval. The current agent may also collect cached process and runtime snapshots at a different cadence than the main host metrics to reduce server overhead.

​
Authentication and Validation

The current backend expects:
  • a bearer token built from the server API key
  • a valid Watchman Tower server_id
  • the request to come from the server IP configured for that server entry
The backend also performs strict request validation in production. If the agent appears to send data but nothing shows up, verify the configured server IP and API key first.
For the current version, the safest practical setup is:
  • use the hosted installer or upgrader wherever possible
  • run the agent as a systemd service
  • keep the API key scoped to the specific server entry
  • verify the service after install with systemctl status wt-warden

​
Troubleshooting Basics

If the agent does not appear in Watchman Tower:
  • verify server_id
  • verify api_key
  • verify api_url
  • verify the server’s public IP matches the configured IP in Watchman Tower
  • confirm outbound HTTPS access from the host
  • review logs with journalctl -u wt-warden -f

​
Next Steps