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:Toolbar
Stat cards: Total Events, Critical, High Severity, Unique Users.
An important scoping caveat
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.
Empty and error states
Related
Users
Act on what a review turns up.
Events
Resource-oriented history.