Reading the audit log
Who signed in, what changed, from where. Filtering the trail, exporting it, and deciding how long to keep it.
- Beginner
- 6 min read
- Applies to 2.0
Turning it on
User Access → Security → Enable Logging. Until it is on, the Audit Log screen shows a notice and nothing else.
Then User Access → Audit Log.
The Audit Log screen: total events, retention, the three filters and the table.
What a row tells you
| Column | What it holds |
|---|---|
| Timestamp | when it happened |
| Category | the family the event belongs to |
| Action | the event itself, in words |
| User | who it concerned, where there was one |
| IP | the address the request came from |
| Device/Browser | what the browser said it was |
| Status | whether it succeeded |
| Resource & Context | what was acted on, and any detail worth keeping |
Two of these open on click: the row itself for the full event detail, and the device column for the raw user agent.
Finding something
Three filters across the top — Category, Status and Event Type — combine, and Clear returns you to the unfiltered list. The table is paginated.
The search box matches the username, the IP address, the event type, and the event's stored detail. That last one matters when you are looking into a failed sign-in: the name somebody tried is in the detail, not in the user column, which only ever holds an account that exists.
The three filters and the search box narrow the same query, and the page count below reflects what you have filtered to — so what the table shows and what the pager promises describe the same set of rows.
What is recorded
Rather more than sign-ins. The events fall into families:
- Authentication — successful and failed sign-ins, sign-outs, password reset requests and their outcomes
- User management — registrations, deletions, role changes, profile and email changes, passwords changed
- Security — too many sign-in attempts, an account locked after repeated failures, an account unlocked by an administrator, resets attempted for an unknown user or with an invalid token, reset emails sent or failed, suspicious activity
- IP management — a visitor refused by the blocked list, and every change an administrator makes to either list: an address added or removed, and which list it was
- Administration — security settings changed, logs exported, logs cleared
- Content — posts, pages, media, comments
- Site changes — plugins, themes, options, permalinks, widgets and menus
Events to Log, in the Settings window, lets you switch families off if the volume is more than you want.
The IP column records the address a request came from. It does not record a country — the plugin has no geolocation of any kind, so nothing here tells you where in the world someone was.
How long it is kept
Settings → Log Retention Period, in days. The default is 30: entries older than that are deleted automatically. The current value is shown on the screen itself, next to the total number of events, so you can see at a glance what window you are looking at.
Coming from version 1.x? Retention had three different names in the settings and the one you edited was not the one being applied — a site set to keep a year's worth was quietly deleting after 30 days, or the reverse. Since 2.0 there is one setting, the one in this window. Open it once after updating and confirm the number is what you intended.
Exporting
Export Logs produces CSV or JSON, and you can narrow it by date range and by event type before you export — hold Ctrl or Cmd to pick several types, or leave All Event Types selected for everything.
The export itself is recorded in the log.
Clearing
Clear All Logs deletes every entry permanently. There is no undo and no partial clear: if you want to keep some of it, export first. This too is recorded — the cleared log's first entry will say it was cleared, and by whom.
Something missing or out of date? Tell support.