How Trinium works
The audit trail
Every action that changes something is recorded with who did it, when, what it was done to, and whether it succeeded, failed or was refused.
What is recorded
- Sign-ins, and failed sign-ins with the exact reason. The sign-in page itself gives every refused attempt the same answer; only the trail says why.
- Accounts created, changed, deactivated and promoted.
- Pipeline and Flow edits, as the nodes or steps added, removed, renamed or reconfigured. Moving a card around is not a change.
- Versions saved, deploys with their notes, runs started with the values they were given.
- Connections created and changed, connection tests, schedules, notification destinations.
- Backups taken, downloaded and restored, and every settings change.
What is never recorded
A secret is recorded as the fact that it changed, never as its value, and no node setting's value reaches the trail: a pipeline edit names the nodes, not what was typed into them.
How it is kept
- It cannot be edited. The database refuses any change to an entry once it is written.
- It outlives accounts. An entry keeps the name of the person who acted, even after the account is renamed or deleted.
- It stays with this instance. The trail is never put in a backup and never replaced by a restore: it is this instance's record of what was done to it.
Reading it
On Enterprise, Settings → Audit shows the trail to the Auditor, Admin and Super Admin roles, with filters, and exports it as CSV. On both editions every entry is also written to the server's log stream under trinium::audit, which a log collector or SIEM can pick up: see Logs.