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

Area	Setting	Effect
Telemetry	Telemetry on/off & options	Whether hosts push telemetry, and all of it or a chosen subset.
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.

A profile’s page, its edit form and the Profile card on a server’s Info tab list its log files in one order: the systemd journal first, then every file by its path, ignoring case. On the edit form, a row you add stays at the bottom until you save.

How often agents report, and how many processes they report on, are not profile settings: WatchTower15 sets them. See Collection settings.

Assigning a host to a profile

Name the profile in the install command, and the host joins it when it enrols:

curl -fsSL https://api.watchtower15.com/api/agent/install-script | sudo sh -s -- <org_token> --profile=web-tier

--profile= takes the profile’s slug or its uuid, both shown on the profile’s page, never its name. For an unattended install, set WT15_PROFILE instead (see Installer options). The installer checks the profile with WatchTower15 before it installs anything, and stops if your organisation has no such profile (see If the profile is not found). It saves the profile in the agent’s configuration, so the agent asks for the same one if the host enrols again as a new server.

The dashboard writes the flag for you:

In the Adding a server drawer (Servers → Add Server), choose the profile in Profile (optional). Organisation default, the first choice, adds no flag. Members who cannot view profiles do not see the list.
On a profile’s page (Servers → Profiles, then the profile), the Install onto this profile card shows the command for that profile, with a button that copies it. Members who can edit servers see the card; those who cannot view the organisation’s settings see <org_token> in place of the token. The card has no proxy fields: for a host behind a proxy, use Add Server.

A host installed without a profile joins your organisation’s default profile.

The install’s profile is used only when a host enrols as a new server: running the installer again on an enrolled host does not move it. To move a server to another profile, use (change) on the Profile card of the server’s Info tab (see Changing a server); the agent picks up the new configuration on its next poll, with no restart.

Because every host installed without a profile lands on the default profile, keep that profile a sensible baseline (see Recommended profile design).

A profile’s slug

A profile’s slug is made from its name when the profile is created (Web tier becomes web-tier, or web-tier-2 when that slug is taken) and never changes after that, even when you rename the profile, so a command or IaC variable that names it keeps working. The profile’s page shows it with a button that copies it, and its edit form shows it read-only.

A deleted profile’s slug is never given to another profile, so a command written for it is refused rather than landing on a newer profile that happens to share its name. Deleting a profile therefore stops every install command that names it, by slug or by uuid; the delete confirmation says so.

Duplicating a profile

Building a near-identical profile from scratch is tedious and easy to get subtly wrong. Duplicate clones an existing profile into a new, independent one: all log files and folders, schedules, telemetry options, the profile’s tags, and its server-led tag-group filter come across. A collection setting that WatchTower15 changed on the source at your request does not: the copy starts from the standard values.

The copy is always a fresh custom profile with no servers bound to it, so duplicating never disturbs a running fleet.
It is named after the source with a Copy suffix — Web servers Copy, then Web servers Copy 1, Copy 2, … if that name is taken. Duplicating a copy continues the series rather than stacking into “Copy Copy”.
The copy is fully independent from the moment it’s created: later edits to either profile don’t affect the other.

The usual workflow is to duplicate a proven profile, adjust the one or two settings that differ, then move hosts onto it.

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:

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

Adding a log file across every web server is therefore a single edit. Each server then imports the file’s last 72 hours, which count as log volume, and that file’s new lines appear once its import has finished (see tailing behaviour).

A host that cannot reach WatchTower15 keeps collecting with the last profile it received, even across a restart (the agent keeps it on the host: see The profile kept on the host), and picks up any change made meanwhile when it reconnects.

Tags on a profile vs tags from the host

Three tag sources combine on every enrolled server:

Profile-assigned tags — applied to every host on the profile. Always kept.
Install tags — given on the install command (--tag=, see Tags at install), applied at the first enrollment whatever the filter.
Server-reported tags — collected by the agent from cloud/Docker/Kubernetes metadata (from a container, only WT15_TAG_<Name> variables), then run through the profile’s include/exclude filter, which WatchTower15 applies server-side on every enrollment and heartbeat.

The final tag set is the union of the three, and runtime tag updates are strictly additive (a tag is never stripped off a running host automatically), with one exception: saving a profile with Sync Tags in Exclusive mode replaces every tag on its servers with the profile’s own, the install tags and the host’s tags included. See auto-tagging and advanced tagging for the full rules and filter behaviour.

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.
Name each profile by the role of its hosts, and keep its slug in your IaC: the slug never changes, even when you rename the profile.
Use a conservative default profile for the organisation: every host installed without a profile starts on it.

Configuration reference — local overrides.
Auto-tagging & Advanced tagging — the tag rules.
Logs overview — how profile log paths become searchable streams.