Audit trail
The audit trail is an append-only record of who did what on a running project. It is an add-on module for the enterprise build: the build itself is activated by a licence key, and the trail appears once a key also authorises this module. See Licensing if the build is not activated yet.
Open a project's editor → Admin → Audit Trail. It sits with the other per-project admin sections, not on the manager dashboard, because the trail is per project: each project has its own file and its own view.
What gets recorded
Operator actions against live equipment, not configuration work:
| Action | Emitted when |
|---|---|
alarm.ack |
An alarm actually moves from unacknowledged to acknowledged |
alarm.ack_all |
A bulk acknowledgement lands |
variable.write |
A write to a PLC variable succeeds |
user.login |
An operator signs in |
user.logout |
An operator signs out (a guest-to-guest logout is not an event) |
Two rules keep the trail honest. A retry, an already-acknowledged alarm, or a rejected write is not an event — otherwise an unauthenticated caller could grow the file by spamming failures. And page, theme, translation, and widget edits are deliberately not audited: those routes sit behind the manager's single shared password with no per-user identity, so there is no actor to attribute an edit to. Recording one would be a fiction.
Reading a record
Each record carries an actor, an action, a subject, a detail, and a timestamp. The actor also carries how its name was established, shown in the panel as a badge:
Verified means the server resolved the name itself from an authenticated connection — the caller could not choose it. Claimed means the caller supplied the name and nothing checked it. A claimed name is still the only lead there is, which is why it is kept, but it is not evidence.
Alarm acknowledgements arrive over REST routes that have no session to draw a verified name from, so they are recorded as claimed. Logins, logouts, and variable writes come over the WebSocket, where the server already knows who the connection belongs to, so they are verified.
Plan for this when you write an audit procedure: if your regulator needs every acknowledgement attributed to a verified identity, the badge is what an inspector will look at, and "claimed" is the honest answer rather than a defect to explain away.
Filtering
The panel filters by actor, by action (e.g. alarm.ack), and by a row limit —
100 by default, 1000 at most. Enter the filters and press Apply. Records
come back newest first; Refresh re-reads without changing the filters.
The scope is always the current project. It is fixed by the process, not chosen in the UI — each project's trail is its own file, so one project's view cannot show another's operator names or alarm codes even by mistake. A contractor working on one low-trust line cannot read another line's history.
Retention
Rotation renames; it never deletes. When a segment reaches its size limit
(32 MiB by default) it is rolled over and kept. How long you must retain audit
history is a legal question for your site, not something the product decides —
silently discarding history is the one behaviour that would make the trail
worthless. Archive or prune the files under <runtime_home>/audit/ according to
your own policy.
Every write is flushed to disk before it is acknowledged, so a power loss on a panel PC costs at most the record in flight, never the file.
The trail belongs to the installation, not to the project folder. It is never included in a project export, upload, or peer transfer. Move a project to another machine and it starts a fresh trail there; the original stays where it was written, which is the property that makes it worth keeping.
When the panel is empty or missing
| What you see | What it means |
|---|---|
| The Admin page has no Audit Trail section | This is the community build. Audit ships only in the enterprise build. |
| "Audit trail not available on this instance." | Either no valid license authorises the module, or this project started before the license was added. Check Settings → Device licenses, then restart the project. |
| "No audit events." | The module is running and the trail is genuinely empty — no acknowledgements, writes, or sign-ins have happened yet on this project. |
See Licensing for adding and checking a license.