What it's for
If you ever need to answer "who changed this?", "did someone try to get in?", or "prove nothing was tampered with" — the audit log is the source of truth. It's append-only (entries can't be edited or deleted) and hash-chained so any tampering is detectable.
Reading & finding entries
- Filter by actor (who), action, area, and date range — or type in the search box for free-text.
- Group by day gives a per-day digest (events · alerts · people); days with alerts auto-expand. Rows load as you open a day.
- Load older pages further back in time.
- Export CSV hands you the filtered rows for a spreadsheet or to send on.
- Verify integrity (the shield chip) recomputes the tamper-evident hash chain and confirms nothing was edited, deleted, or re-ordered — or points at the exact entry where the chain breaks.
What every field means
Each entry can carry these details. Not every event fills every field — a sign-in has no "records touched", for instance.
| Field | What it means |
|---|---|
| When | The exact time the event happened (your local time). |
| Actor | Who did it — the username + their role. System/automation actions are labelled as such. |
| Action | What happened — e.g. signed in, role changed, lead updated, failed sign-in. |
| Area | The module the action touched — e.g. users, leads, settings, audit, security. Use it to narrow "everything that happened in Users". |
| Target / Summary | The specific thing acted on and a readable one-line description. Sensitive changes include a before → after diff. |
| Status | The outcome — ok, denied (blocked, e.g. no permission), or failed. |
| Severity | How notable it is — routine vs. worth attention (privileged changes, denials, bursts rank higher). |
| IP & Geo | The network address, and where it looked to come from — country, region, city, and network (ASN). Rough, offline-derived location — a signal, not a GPS fix. |
| Device | The kind of device/browser the action came from (from the browser's user-agent). |
| Auth method | How the actor was authenticated for this action — e.g. password, password + 2FA, a service token. |
| Session | The session id — a tag for one sign-in. All actions from the same login share it, so you can follow "everything this person did in this session". |
| Correlation | The correlation id — ties together the several log lines that belong to one operation (e.g. a single request that checked access, wrote a change, and logged it). Same correlation id = same underlying action. |
| HTTP method · route · status | The web request behind the event: the method (GET/POST…), the route it hit, and the response code — 200 = ok, 403 = denied, 404 = not found, 5xx = server error. Useful for pinning down denied or failed attempts. |
| Records touched | How many records the action read or changed — flags bulk operations and data exports. |
Manage retention — what it means
Retention controls how long audit history is kept, in three tiers. You set each as a number of days, and they must go hot ≤ warm ≤ cold:
Hot
- The dashboard's default window (e.g. last 7 days).
- What you see first, instantly.
Warm
- Kept live and fully queryable (e.g. 90 days).
- Filter/search reaches back this far.
Cold
- Archived but retrievable (e.g. 365 days).
- Compressed + sealed; verify still passes across it.
Beyond cold
- Purged — permanently removed.
- Set cold to how long you must legally keep records.
Who manages it — governance
One side owns the audit trail at a time (there's deliberately no dual control):
- Managed — Larauna operates and monitors it for you; the panel is our control surface.
- Self — your own admins operate and monitor your trail, including retention.
- View — read-only visibility for the non-owning side (e.g. you watch while we investigate on your behalf) — no config or retention control.