← Learning library
LaraunaManaged automation & care
Security · Audit log

Using the Audit log

The audit log is a permanent, tamper-evident record of who did what, when, and from where in the admin — every sign-in, access change, and edit. This guide shows how to read it, filter it, and what every field means.

Prepared for   Date   

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.
At the top, a security-signals strip highlights things worth a glance — failed-login bursts, privileged changes, denied attempts, and data exports in the last 24 hours.

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.

FieldWhat it means
WhenThe exact time the event happened (your local time).
ActorWho did it — the username + their role. System/automation actions are labelled as such.
ActionWhat happened — e.g. signed in, role changed, lead updated, failed sign-in.
AreaThe module the action touched — e.g. users, leads, settings, audit, security. Use it to narrow "everything that happened in Users".
Target / SummaryThe specific thing acted on and a readable one-line description. Sensitive changes include a before → after diff.
StatusThe outcome — ok, denied (blocked, e.g. no permission), or failed.
SeverityHow notable it is — routine vs. worth attention (privileged changes, denials, bursts rank higher).
IP & GeoThe 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.
DeviceThe kind of device/browser the action came from (from the browser's user-agent).
Auth methodHow the actor was authenticated for this action — e.g. password, password + 2FA, a service token.
SessionThe 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".
CorrelationThe 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 · statusThe 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 touchedHow 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.
Longer retention = more history for investigations, but more storage. Set cold to your compliance requirement (often 12 months), then hot/warm for how far back you routinely look.

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.
© Larauna · Using the Audit log · v1Questions? Contact your Larauna administrator.