📚 Browse docs

Audit log

The Audit log answers “who ran the failover”, “who deleted that shadow”, and “who changed this setting”, with a record designed so the answer can’t be quietly edited afterwards.

Admin only.

What is recorded

Privileged and state-changing actions. Routine read-only polling is deliberately not recorded: if every dashboard refresh were logged, the entries that matter would be buried in noise. What you get is the trail of things that actually changed something.

Each entry captures the actor, the action, the outcome, and when. The periodic background cleanup that reclaims orphaned shadow directories writes an entry naming what it reclaimed whenever it did something.

Tamper evidence

The log is append-only and hash-chained: every entry carries a hash of the entry before it. Editing a row, or deleting one outright, breaks the chain from that point on.

Beyond the hash chain, each entry is sealed with a key kept outside the database, and the newest sealed entry is anchored locally, so a log that was re-linked, truncated or rewritten by someone holding only a copy of the database fails verification. Each paired site also holds an anchor for this site’s log (a statement signed by this site’s own key, kept on the other site’s machine and refreshed about every minute), so a log rewritten on this controller alone can’t agree with it. A shorter log, a different hash or a paired site that stops answering raises the critical peer_audit_diverged or peer_audit_anchoring_lost alert.

Run the verification from this page at any time. If the chain is intact it says so; if it isn’t, it reports the exact entry where the chain first breaks, so you know both that something was altered and where.

The verdict reports the seals, the local anchor and each paired site’s anchor separately, because they are not the same claim: entries an older version wrote unsealed, or sealed with a key that is no longer available, are reported as unverifiable rather than as tampering. An admin can Acknowledge a finding they have investigated, Rotate key, and Accept a paired site’s current log as the new baseline after a divergence; each is recorded in the audit log. The same checks run from a shell, with no daemon needed, and against an exported copy of the log: see CLI tasks.

This matters for a DR product specifically. An audit trail that can be silently rewritten is worth very little in the post-incident review that follows a real failover: the review where someone asks whether the failover was authorised.

Filtering

Narrow the trail by free text, actor, action, outcome, or a From / To date range. Actors and actions come from the data itself, so the dropdowns only offer values that actually occur.

Export CSV downloads the trail: the whole log, or exactly the filtered view when a filter is active (the link says so). Hand it to an auditor, or diff two exports.

The list is paged, newest first; Newer / Older walk it and the footer shows where you are (1–100 of N).

  • Users & security: the accounts and roles the actor column refers to.
  • Operations: the operational view of the same runs.
  • Settings: dual-control approval, which pairs naturally with an audit trail.