Audit trail

An audit trail is a baseline requirement for any platform that touches production infrastructure. WatchTower15 records what happens in your organisation: what people change, what your servers’ agents report about themselves, and what the platform decides on its own — an incident opening, a health change, a DNS change detected. The Audit page shows all of it, and each resource’s page shows its own part on its Audit tab: one list, in two places.

What’s recorded

Two kinds of event are recorded:

Events about a resource — one of your servers, databases, domains, services, log sources, custom metrics, metric sources or server profiles. Together they make up that resource’s Audit tab.
Organisation events — sign-ins, users, roles, SSO, billing and account limits, which belong to no single resource.

Changes to a resource

Every save records one event listing what changed, old → new. A save that changes nothing records nothing.

Free text — notes, descriptions, a service’s expected response text — and fields that can carry a credential — a service’s request headers, request body, parameters and authentication — are recorded only as added, changed or cleared. Their text is never recorded.
Tags are recorded by name, as added or removed. Tags a profile pushes onto its servers are recorded on each server whose tags changed, with the detail Via profile: and the profile’s name. Likewise, a tag change a metric source applies to its metrics is recorded on each metric whose tags changed, with the detail Via metric source: and the source’s name, and the source’s own event carries Applied to metrics: and how many changed.
Moving a server to another profile records the old and new profile names.
A server profile’s collections — telemetry options, log files, log folders, schedules and server-led tag groups — are recorded as changed, with their counts.

Creating or deleting a resource is recorded too. A server’s record begins with its enrollment.

Enrollment and the agent

Enrollment token provisioned — by the person who issued the server its token.
Server enrolled — by the agent, with how it enrolled (automatically or manually approved), its agent version and the profile it joined, and, when its install command gave tags, the Install tags applied and the Install tags dropped with why (Team=old-team: deleted). The groups and tags they created read just below it.
Server held — limit reached — by System, when a server enrolls after your server limit is reached, with the limit and how many servers were in use. It appears just above the server’s Server enrolled event.
Server approved, Server access revoked and Server token rotated — by the person.
Server archived — by the person who archived the server, or by System: when WatchTower15 archived it for silence, reading Silent for 7 days (the days since its agent last checked in), or when your teardown automation archived it, reading By teardown automation.
Server reactivated — by the person who reactivated it, or by System when its agent reported again after it was archived for silence, reading Its agent reported again, or by the agent, just below its Server re-enrolled, when an agent installed again on the host brought the archived server back.
Server re-enrolled — by the agent, when an agent installed again on the host continued the server, with its agent version, when the previous agent was last seen, and whether that agent had powered off; and the agent version change, old → new, when the new install runs another version.
Agent upgraded — by the agent, old → new version, and only when the version really changes.
Server rebooted — by the agent.
Tag group created and Tag created — by the agent, when a tag the host reports needs a tag group or tag your organisation does not have yet; the event names the server it came from. See how reported names are stored.
First data received — by the agent: telemetry or logs, whichever arrived first.
Connectivity lost and Connectivity restored — by System, together, for each gap of 5 minutes or more in which nothing was heard from the server’s agent, once the gap is complete: its cause settled and the data the agent kept delivered or given up. Connectivity lost gives when the gap started, its causes in order and the most frequent connection error with how many times it happened: Since 09:12 UTC · No connection from the host (DNS lookup failed, 412 times). Connectivity restored gives when the agent was heard again, how long the gap lasted and what became of its data: At 11:25 UTC, after 2 h 13 min · All data recovered, or the parts, largest first, such as 2 h 30 min recovered, 40 min dropped on the host, 1 h not collected (host down) or 2 h 13 min not kept by this agent version. Time the server was powered off, held, paused or awaiting approval is named apart and is never a loss; a gap made only of such time records neither event. They carry the kind of error, never its message, and record the gap as it stood when it was complete: the server’s banner follows anything the agent reports about it later.

Alarm configuration

Recorded on the resource the alarm belongs to:

Alarm created, Alarm updated, Alarm deleted, Alarm duplicated and Alarm reset (back to its profile). Saving a resource’s edit form records one event per alarm that actually changed, and editing an alarm inherited from a profile records that it now overrides its template.
Profile alarm templates applied — one summary event on each resource, naming the person whose change applied them, or System when WatchTower15 applied them itself.
Default alarms added — by System, and only when something was actually created.
Alarms deactivated — when you switch off a domain’s scanning (the reason names the scans switched off, such as scanning turned off: DNS Change), or when changing a custom metric’s type leaves an alarm with an aggregation the new type doesn’t support.
Alarm template created, updated or deleted — on the server profile’s Audit tab.
Alarms unlinked from their template — when the template or its profile is deleted. The alarms stay on the resource as its own.

Incidents

Incident triggered — by System, from a scheduled evaluation or a scan.
Incident escalated or Incident de-escalated — one event for a change of severity.
Incident acknowledged — by the person.
Incident resolved — by the person who resolved it by hand, or by System with the reason: the condition cleared, the alarm was deleted or disabled, the alarm was removed from the profile, the resource moved to another profile, the resource is inactive or deleted, or the server was archived or deleted.

Incident events are recorded whatever the alarm’s notification settings, so a resolve nobody was notified about still appears. See the incident lifecycle.

Health

Health changed — by System, old → new, and only when health actually changes. A log source or metric source starts as Unknown; the move to Healthy that its first data brings is recorded as part of its First data received event.

First data received

Recorded when a server, log source, metric source or custom metric first sends data. For a server, that is its first telemetry or logs, whichever arrived first. For a custom metric, only a recent point counts — backfilled history does not — and it is recorded again after Delete stored data.

Detected changes

On a domain, Change detected is recorded when a DNS, SSL certificate, domain registration or WHOIS scan finds something changed. It names the fields that changed — never their values — and links to that check’s Change History page, where the values are. A domain’s first scan (its baseline) and a flip back to a value already reported are not recorded as changes.

A DNS change can also open an incident, so both can appear: what the scan saw, and what the alarm concluded. See change detection.

Account limits and courtesy

When WatchTower15 changes your organisation’s account limits or courtesy status, the change is recorded by System, under the Organisation resource type, with a short summary of what changed:

Event	Example summary
Account limit or exemption set	Server limit set to 10, Courtesy account until 5 Oct 2026
Account limit or exemption removed	Server limit removed (back to the default), Courtesy account ended
Account preset applied	Account limits updated: Courtesy account until 30 Nov 2026; Server limit set to 5; … — every limit applied together, in one event

Like other organisation events, these appear on the Audit page only.

Sign-ins and organisation events

Events about users, roles, SSO, billing and account limits appear on the Audit page only, alongside sign-ins:

Event	Details captured
Login success	The method (`password`, `passkey`, `sso`, or `registration` for the session that starts when you register), and for SSO the provider (`google` / `microsoft`).
Organisation registered	The organisation was created by registering: its industry, company size, country and the version of the Terms accepted.
Billing details updated	A change to the billing details. A change of billing currency is listed old → new.
User registered	A new account was created by registering the organisation.
Login failed	A structured reason — e.g. wrong credentials, account locked, password disabled for an SSO-only org, email not verified, or an SSO domain restriction.
Logout	The signed-out session.

Who did it

Every event records who, or what, did it:

Who	Means	Reads in the list	Also recorded
A person	A member of your organisation, acting in the app.	Their name	The IP address, user agent and request URL.
WatchTower15	WatchTower15 itself — opening and auto-resolving incidents, changing health, detecting a change, adding default alarms, holding a server at your server limit, archiving a server for silence or for your teardown automation, reactivating one whose agent reported again, and changes WatchTower15 makes to your account limits.	System	No IP address, user agent or URL.
A server’s agent	A server’s own agent — enrolling, upgrading, rebooting, sending its first data, creating tag groups and tags from the host’s tags.	System	The IP address, user agent and URL of the agent’s own request.

So an event no person did reads System on the Audit page and on the Audit tab, whether WatchTower15 or a server’s agent did it.

Each event also carries a resource type, what it is about, and its details: what changed, old → new, or event-specific context such as the SSO provider or the reason a login failed.

Resource types

Every event is filed under a resource type, shown in the Audit page’s Resource Type column and picked with its Resource Type filter, which groups the types by area. A resource type names the kind of thing that changed. Changes and lifecycle events file under their resource — Server, Database, Domain, Service, Log Source, Custom Metric, Metric Source or Server Profile — and so does a change a scan detected: a change to a domain’s DNS, certificate, registration or WHOIS details files under Domain. Alarm configuration files under Alarm Rule, alarm policies under Alarm Policy, alarm channels under Alarm Channel and contact groups under Contact Group; incidents file under Alarm Incident and health changes under Health. Sign-ins and organisation events have their own, such as Authentication, User, Role and Organisation (account limits and courtesy status).

The Audit page and the Audit tab

The audit trail is one list, shown in two places:

	The Audit page	A resource’s Audit tab
Where	Organisation → Audit	The Audit tab of a server’s, database’s, domain’s, service’s, log source’s, custom metric’s, metric source’s or server profile’s page
Lists	Every event in your organisation	The events about that one resource
Who can open it	Holders of `audit.view`	Anyone who can view the resource

The Audit tab is the Audit page locked to its resource, not a separate log. It reads the same way, and leaves out only what would point it at another resource and what your role does not let you see. Each table below says what the tab shows.

Columns

Events are listed newest first, 25 to a page; pick 10, 25, 50 or 100 below the list.

Column	Shows	On the Audit tab
Date & Time	When the event happened, in your date format with seconds, such as `06/10/2026, 14:03:22`. The header names your timezone once, as in Date & Time (BST), and a time on the other side of a change of clocks names its own. Hover over a time to see it in UTC too.	Yes
User	Who did it: the person, or System when no person did (Who did it). A member who has since been removed reads (deleted). With `users.view`, the name links to the person’s page under Organisation → Users.	Yes
Resource Type	The resource type the event is filed under.	No
Action	The event, and under it how many fields it changed, such as 3 fields changed. Some events link elsewhere (below).	Yes
Resource	What the event is about, linked to where it lives (below).	No
IP Address	The address the request came from. Empty for WatchTower15’s own events.	With `audit.view` only

Filters

The filters sit on the left of the row above the list, the lanes first, and the time window on its right:

Filter	Shows the events	On the Audit tab
All · Changes · Alarms · Incidents · Health · Lifecycle	In one lane	Yes
Resource Type	Filed under one resource type, picked from a list grouped by area	No
User	That one person did	For holders of `audit.view` or `users.view`
Resource	About a resource whose name contains the text you type (below)	No
The time window	In the window. It opens on the last 5 days; pick `1h`, `3h`, `12h`, `1d` or `5d`, or Custom, a length of your own or a range on the calendar, for anything older	Yes

The filters combine. Clear all filters, the first button in the row, clears them and sets the window back to the last 5 days. Your filters are remembered for your next visit: the Audit page’s, and apart from them those of each kind of resource’s Audit tab. Times are shown in the timezone set in Profile → Preferences (your browser’s by default), and a range from 09:00 starts at 09:00 in that timezone (Times & timezones).

Lanes

Lane	Shows
All	Everything.
Changes	Everything the other lanes don’t: edits, changes a scan detected and, on the Audit page, sign-ins and other organisation events.
Alarms	Alarm and alarm-template configuration.
Incidents	Incident events.
Health	Health changes.
Lifecycle	Creation, enrollment and re-enrollment, servers held at the server limit, approval, revocation, a server’s archive and reactivation, tokens, agent upgrades, reboots, a server’s timezone change, connectivity lost and restored, first data received, custom metric approval, profile duplication, a database’s pausing, resuming, accepted key and collector changes, and registering your organisation or account.

The count and the pages cover only the lane you picked.

Opening an event

The arrow at the start of a row opens the event below it, on the same background, in words:

What changed, one line per field: Label: old → new. A list, such as a resource’s tags, reads as what was added and removed: Tags: +prod, −staging. A field whose text is never recorded reads added, changed or cleared.
The event’s details, one line each: an incident’s alarm, severity and message, an alarm’s template or profile, a reason, the fields a scan found changed, the metric source that passed a tag change down, and how many metrics it applied to (Via metric source: Checkout API, Applied to metrics: 10). Values read as words (Severity: Critical), on/off values as Yes or No, and times in your date format.
Connectivity lost and Connectivity restored read as one line each, as described in Enrollment and the agent. So do Server archived and Server reactivated when System wrote them: Silent for 7 days, By teardown automation or Its agent reported again. When a person did, the User column names them, and the event adds no such line.
User agent and URL, the request’s, for holders of audit.view.

An event with nothing more to show has no arrow.

Links from an event

The Action column links two kinds of event:

Change detected links that check’s Change History page, for holders of domains.view.
An incident event links where the incident is listed:
- on the Audit page, the incident’s own page under Alarming → Incidents, for holders of incidents.view;
- on an Audit tab, the resource’s own incidents: the Incidents tab of a server, a database or a domain, opened on every status and on a time window that holds the event, or the Incident History page of a service, log source or custom metric. A server’s or a database’s needs only its view permission; a domain’s, service’s, log source’s or custom metric’s needs incidents.view too. An incident on a server’s volume, listening port or systemd unit links its server’s Incidents tab.

Without the permission, the event is named but not linked.

The Audit tab

A resource’s Audit tab lists the events about it: the Audit page’s list, locked to that one resource. Servers, databases, domains, services, log sources, custom metrics, metric sources and server profiles each have one.

On a server’s, a database’s or a domain’s page it is the last tab, after Info. The other pages have two tabs: Overview, which holds everything else on the page, and Audit. The tab has its own address — the resource’s page followed by /audit — so you can send someone a link that opens it directly.

Locked to its resource, the tab has no Resource Type or Resource filter and no Resource Type or Resource column. Open in Audit Trail →, at its top right, opens the Audit page filtered to this resource, for holders of audit.view.

Who can see the Audit tab

The Audit tab has no permission of its own. Anyone who can view the resource can open it — servers.view, database.view, domains.view, services.view, log_sources.view, server_profiles.view, or custom_metrics.view for custom metrics and metric sources — and sees every event in it, incidents and alarm changes included. Other permissions add to it:

Permission	Adds to the Audit tab
`audit.view`	The IP Address column, the user agent and URL in an opened event, the User filter, alarm policies named in a change, and Open in Audit Trail →
`users.view`	The User filter, and each person’s name linked to their page
`incidents.view`	Links from incident events on a domain’s, service’s, log source’s or custom metric’s tab. A server’s and a database’s tab link them without it
`policies.view`	Alarm policies named in a change, rather than counted, as in +2 policies

Without audit.view, WatchTower15 never sends the IP address, user agent, URL, the actor’s email address or the raw event details to your browser, so they cannot be read from the page or from the API either.

Acting is gated as everywhere else: acknowledging or resolving an incident needs incidents.edit, and changing an alarm needs alarms.edit.

The Audit page

Organisation → Audit lists every event in the organisation, with the IP address of each request and, in an opened event, its user agent and URL. It is gated by the audit.view permission, so you can grant auditors read access to activity without granting them any operational rights. Its columns, filters and links are described above.

The Resource column

The Resource column names what each event is about, and links to where it lives:

Event about	Named	Links to
A server, database, domain, service, log source, custom metric, metric source or server profile	Its name	Its page
A server’s port, volume or systemd unit	The server and the port, mount point or unit, such as web-01 · /data	Its drawer on the server’s page
A dashboard	Its name	The Dashboard page with that dashboard open
A tag or tag group	Its name	Organisation → Tags
An alarm policy, alarm channel or contact group	Its name	Its page
A role	Its name	Its page
A person: their sign-ins, their profile, an invitation, a contact method or a passkey	The person, with the contact method’s type (Jane Doe · SMS) or the passkey’s name	The person’s page under Organisation → Users
The organisation’s billing or account limits	Your organisation	Organisation → Billing
The organisation’s settings, its install token or an SSO domain	Your organisation, or the SSO domain	Organisation → Settings

A contact method is named by its type only: its phone number or address never appears on the Audit page.

A link appears only when you hold the view permission of the page it opens. Without it, the subject is named but not linked. Some subjects are named but not linked for everyone:

one that has since been deleted, marked (deleted);
a person who is not a member of your organisation, such as an invitee whose invitation was revoked;
another member’s private dashboard;
a resource that belongs to another organisation, which a few older events, recorded before events carried their organisation, can name.

The filter icon beside the name narrows the page to that one subject, shown as a removable Resource: … chip — which is also what Open in Audit Trail → opens. Filtered to one resource, the page lists exactly the events that resource’s Audit tab lists. For a person, and for their contact methods, passkeys and invitations, the icon narrows the page to everything about that person, shown as an About: … chip: their sign-ins, their profile and contact changes, and their roles and status in your organisation. That is a different question from the User filter, which lists what a person did, and from the Resource filter, which finds every resource whose name contains your text.

The Audit page is also where to find what no Audit tab shows: events about anything without an Audit tab of its own, organisation events, and resources that have been deleted.

Two smaller views draw on the same trail:

Recent logins — each user can see their own last few successful logins (time, IP, method), a simple self-service way to spot an unexpected session.
Audit feed — a dashboard widget listing people’s most recent actions. Events recorded by WatchTower15 or by a server’s agent stay on the Audit page and on each resource’s Audit tab.

Finding a resource by name

Type part of a name in Resource, in any case, and the page lists the events about every resource whose name contains it, deleted resources included, so you can still find what happened to a server that is gone. The name searched depends on the kind of resource:

Resource	Matched on
Server	Its display name or its hostname
Custom metric	Its name or its key
Log source, metric source	Its name or its slug
User	Their name or their email address
Server profile, domain, database, service, tag, tag group, alarm channel, alarm policy, contact group, role	Its name

A user’s name also finds the events about their contact methods, passkeys and invitations, which the Resource column names after them.
An alarm’s events are recorded on the resource the alarm watches, so they are found by that resource’s name, not the alarm’s.
A server’s ports, volumes and systemd units are not searched by name: use the filter icon beside one in the Resource column.
Up to 500 resources of each kind match, the most recently added first. If more match, type more of the name to narrow it.
% and _ are matched as themselves, not as wildcards.

Retention and integrity

Events are kept indefinitely and are not automatically pruned, so historical access reviews stay complete. An event’s content is never changed after it is written.

Roles & permissions — audit.view, the view permissions that open each resource’s Audit tab, and what users.view, incidents.view and policies.view add to it.
Alarms & alerting — the incident lifecycle the Audit tab records.
Uptime, domain & service checks — change detection and Change History.
Single sign-on — the login events the trail records.
Account limits & courtesy accounts — the limits and courtesy status these events record changes to.