Audit Log
An Admin reads the audit log under Settings > Audit Log, filtered by actor, action type, and date range.
Members have no access to it at all, because its entries expose what other users did.
What an Entry Holds
Every entry has the same shape, and every capability in the product writes into it rather than inventing its own logging:
| Field | What it holds |
|---|---|
When |
The timestamp of the action. |
Actor |
Always a person. Where automation acted, the actor is the person whose API token it used, with the token named beside them. |
Action and target |
What was done, and what it was done to. For a credential, the target is its label. |
Outcome |
Whether it succeeded. |
Via |
Whether the action arrived through an interactive session or an API token. |
Source |
The network address the request arrived from. It is the address of the connection itself, never a value the client supplied, so behind a proxy it is the proxy’s address. |
The via field is why the actor column is worth reading. Automation is somebody’s automation, and an actor column full of machine names answers "what ran" in place of "who is answerable".
No secret ever reaches an entry: not a Forwarder access key, not an API token, not a stored mail password.
What Is Recorded
Every entry is something a person did. That is the membership rule, and it is what keeps the shape free of exceptions: each entry has an actor to name and an outcome that means something.
The event set is:
-
Sign-ins, failed and successful (
LOGIN_SUCCEEDED,LOGIN_FAILED) -
Membership: invitation sent, invitation accepted, suspend, unsuspend, remove, role change, and an Admin-triggered password reset (
MEMBER_INVITED,INVITE_ACCEPTED,MEMBER_SUSPENDED,MEMBER_UNSUSPENDED,MEMBER_REMOVED,MEMBER_ROLE_CHANGED,MEMBER_PASSWORD_RESET) -
Self-service password reset, requested and completed (
PASSWORD_RESET_REQUESTED,PASSWORD_RESET_COMPLETED) -
Forwarder registered, renamed, re-tagged, key reissued, disabled, enabled, and deleted (
FORWARDER_REGISTERED,FORWARDER_RENAMED,FORWARDER_TAGS_CHANGED,FORWARDER_KEY_ROTATED,FORWARDER_DISABLED,FORWARDER_ENABLED,FORWARDER_DELETED) -
API token created and revoked (
API_TOKEN_CREATED,API_TOKEN_REVOKED) -
Vulnerability data uploaded and rolled back (
VULN_DATA_UPLOADED,VULN_DATA_ROLLED_BACK) -
Email: settings changed, template changed, template restored (
EMAIL_SETTINGS_CHANGED,EMAIL_TEMPLATE_CHANGED,EMAIL_TEMPLATE_RESTORED) -
Exclusion groups: created, updated, and deleted (
EXCLUSION_GROUP_CREATED,EXCLUSION_GROUP_UPDATED,EXCLUSION_GROUP_DELETED)
An exclusion group entry names the group. Entries written by earlier versions for changes to the former licensing policy (LICENSING_POLICY_CHANGED) stay in the log and are shown as Licensing Policy changes. No new entry of that kind is written. See Licensing Alerts.
Entries are captured regardless of volume. Nothing is suppressed, deduplicated, or rate-limited when it is written.
A successful sign-in is recorded once its tenant is known. A failed one is recorded for every tenant the presented username belongs to, and where it belongs to none, for every tenant, because such an attempt is attributable to no tenant and carries no tenant’s data.
Where Other Events Are Recorded
A quota threshold crossing and a Forwarder connection refused for an unrecognised key are not performed by a person, so they are written to your application log, where the rest of what the machinery does already goes. A refused key is logged as unrecognised and never with the key itself.
Creating, deleting, or scheduling a migration wave and generating its recipe are the work the product exists for, and they are recorded on the wave itself. Changes to exclusion groups change what everybody sees, so those are audit entries. See Licensing Alerts.
Immutability
No path through the product edits or deletes an entry, including for the Admin who performed the original action.
That holds at the storage layer rather than being a missing button: every column is mapped non-updatable, so nothing in the application has an update to issue, and reading is the whole surface the path offers. The guarantee is about the product. Your installation owns its own database, so anyone holding the database file and a SQL client is outside that guarantee, which is one more reason the data volume is worth protecting as you protect a backup.
Retention
Entries are kept indefinitely. No schedule removes one, and there is no cutoff past which the log forgets, on the same basis as the observation dataset.
The log begins when the installation is first started.
The entry count is published as a metric, so the growth of the log is something you can watch rather than estimate. See Monitoring and Health.