Overview

The audit log records who did what, when, and from where. Where Events is organised around resources, this is organised around actions and the people who took them — which is what you want for an access review or an incident.
Navigation: Organization → Audit Log. Titled Audit Log, subtitled “Security and activity audit trail”.

Columns

Each row has a copy button that puts {action} · {user} · {timestamp} · {ip} on your clipboard — handy for pasting into a ticket.
IP Address is unique to this screen. Events doesn’t record it, which is the main reason to come here for a security question rather than a functional one.

Severity

Severity is assigned by action type, not chosen by anyone:
The Critical set is worth knowing by heart, because it’s the list of actions that either remove access or destroy resources. Reviewing Critical entries weekly is a cheap, high-signal habit.

Toolbar

Stat cards: Total Events, Critical, High Severity, Unique Users.

An important scoping caveat

The platform pages this log 25 records at a time, and the timeframe, severity, and search controls filter only within the page you’re looking at — not across the whole log.Two visible consequences:
  • The stat cards describe one page. You can see 1,482 events in the header while Total Events reads 3. Both are correct: the header is the server-wide total, the card counts the current page.
  • Export writes only the filtered current page, not the whole log. A CSV is not a complete extract.
To review a period properly, page through it rather than trusting a filtered count.

Audit Log versus Events

Worked example: a quarterly access review

1

Set the timeframe to 30d and severity to Critical

Critical covers exactly the actions that remove access or destroy resources.
2

Page through rather than trusting the count

Because filters apply per page, walk the pages instead of reading the stat card. The footer shows Page {n} of {m}.
3

Check every role change

Switch severity to High and look for role changes. Each one should correspond to something you can account for.
4

Look at the IP addresses

Actions from unfamiliar addresses are worth asking about, particularly Critical ones.
5

Export what you reviewed

Export produces audit-log-{date}.csv for the current filtered page. Export each page you reviewed if you need a record — one export is not the whole quarter.
6

Cross-check against the user list

Compare against Users. Anyone still Active who shouldn’t be gets disabled.
Only 30 days are reachable through the timeframe control. If your retention requirement is longer, export regularly rather than assuming older history will still be there when you need it.

Empty and error states

Users

Act on what a review turns up.

Events

Resource-oriented history.