Skip to content

Audit log

Every write operation (create, update, delete) on relevant tables lands in audit_log. With a diff between old and new, an author, and a timestamp.

Contents

Field Meaning
id entry UUID
tenant_id tenant scope (NULL for cross-tenant actions)
actor_id / actor_email who did it
action e.g. host_create, dashboard_update, dashboard_soft_delete, auth.login_success
target_type e.g. host, dashboard
target_id UUID of the affected resource
detail JSONB with extra info (e.g. changed field names)
old_values / new_values JSONB with values before/after the change
admin_action_category category automatically derived from the action, used by the quick filters
created_at time

There is no separate IP-address field — but for logins (including failed attempts) the source IP is part of the details. Every entry with content can be expanded to show the details in full, plus the before/after comparison. From v1.9.437 changes to the SMTP settings (password only as "changed: yes/no"), licence key changes (only the first six characters of the key) and generated offline bundles for agent/collector are logged as well.

Redacted fields

The following fields always appear as [REDACTED] in the audit log, even when changed — never as plaintext:

  • password_hash
  • two_fa_secret
  • two_fa_email_code_hash / two_fa_email_code
  • token_hash
  • key_hash
  • snmp_community
  • field_encryption_key

Diff view

/audit → collapsible rows with diff highlighting between old_values and new_values, colored red/green.

Filters

Filter Example
Action e.g. only dashboard_soft_delete
Target type only host
Target ID only changes to a specific resource
Search substring across actor, action and detail contents
Category quick-filter category
Period created_from / created_to
Minor actions hidden by default (preference updates, saved filters, token refresh) — toggle to show them

Quick filters

Three pre-built queries save assembling the free filter by hand: Login attempts, Destructive actions (delete/purge/restore/import over the recent days), and Mode changes.

Visibility levels

Three permissions control how much a user sees:

Permission Effect
audit_log.view_own own actions only
audit_log.view_tenant all actions within your own tenant scope
audit_log.view_global all actions, cross-tenant (super admin automatically)

In the user portal (as opposed to the admin area), the view is always limited to "own actions" regardless of permission level — even for super admins.

Audit on host detail

The History & analysis tab on a host detail page contains a "Change history" section — the same audit view, but fixed to target_type=host and that host's ID.

Retention

Automatic cleanup deletes audit entries older than 730 days (2 years) in a daily background run. There's no license-tiered retention period.

Security

  • The audit log is read-only via the UI — no edit endpoints
  • There's currently no CSV/JSON export endpoint and no manual purge endpoint for the audit log — cleanup runs exclusively via the automatic 730-day rule

Compliance

When an auditor asks "who changed dashboard X on date Y?":

  • /audit?target_type=dashboard&target_id=<uuid>
  • sort by date, expand each entry
  • the diff shows old and new values
  • the author (email) is visible

Next