Skip to content
WatchTower15 Docs

Fleet & profiles

A single server is easy. A fleet of hundreds is where monitoring tools sink or swim. WatchTower15 manages fleets with server agent profiles: a named bundle of configuration that many hosts share, edited once and propagated to every enrolled agent automatically.

What a profile controls

Section titled “What a profile controls”
Area Setting Effect
Collection Telemetry interval How often each host pushes telemetry.
Collection System-info interval How often the fuller snapshot is pushed.
Logs Log files & folders Which paths agents on this profile tail and ship.
Tagging Server-led tagging Whether agents self-report tags, and the filter applied.
Tagging Assigned tags Tags every host on the profile receives regardless of self-reporting.

Assigning a host to a profile

Section titled “Assigning a host to a profile”

A host picks up its profile at enrollment via the WT15_PROFILE_SLUG environment variable (or the organisation’s default profile if none is given):

Terminal window
export WT15_PROFILE_SLUG=production-servers
curl -fsSL https://watchtower15.com/install.sh | sh -s -- <org_token>

This means a golden image or IaC module can bake in a profile slug, and every instance launched from it lands in the right configuration group on first boot.

How changes propagate — configuration etags

Section titled “How changes propagate — configuration etags”

Agents don’t need to be restarted or re-provisioned to pick up a profile change. Each agent polls its configuration and the backend returns an X-Agent-Config-Etag header. When you edit a profile:

  1. The profile’s configuration document is recomputed and its etag changes.
  2. On the next poll, each agent on that profile sees the new etag.
  3. The agent fetches the updated configuration and applies it — new intervals, new log paths, new tagging rules — with no downtime.

Retuning an entire fleet’s telemetry interval, or adding a log file across every web server, is therefore a single edit.

Tags on a profile vs tags from the host

Section titled “Tags on a profile vs tags from the host”

Two tag sources combine on every enrolled server:

  • Profile-assigned tags — applied to every host on the profile. Always kept.
  • Server-reported tags — collected by the agent from cloud/Docker/Kubernetes metadata, then run through the profile’s include/exclude filter.

The final tag set is the union of the two, and runtime tag updates are strictly additive (the agent never strips a tag off a running host). See auto-tagging and advanced tagging for the full rules and filter syntax.

Section titled “Recommended profile design”
  • Start with a small number of behavioural profiles and let tags carry the fine-grained identity.
  • Put noisy or high-volume log paths on their own profile so you can tune their batching independently.
  • Use a conservative default profile for the organisation so an un-slugged host still enrolls sensibly.
Section titled “Related”