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.
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.
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.
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, or outcome. Actors and actions come from the data itself, so the dropdowns only offer values that actually occur.
Results are capped server-side. If a query returns exactly the cap, Asternodis tells you there may be older matches and asks you to narrow the filter — rather than silently truncating and letting you believe you’ve seen everything.
Related
- 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.