The question you cannot answer without one
A page's price changed. A plugin appeared that nobody installed. A user account has a new email address. On a site with more than one person in wp-admin, "who did this and when" is unanswerable from WordPress itself: revisions cover post content and nothing else, and there is no record of logins, settings changes, plugin activations or user edits at all.
An activity log answers it. It is the first thing you open in an incident, the thing a client asks for when their site changed and they did not do it, and the thing auditors mean when they say "access logs".
What a useful log records
Install Dragon Activity Log and it starts recording immediately under Tools, then Activity Log:
- Content changes with field-level detail. Not "post updated" but which fields changed, with the before and after values.
- Logins, logouts, failed logins and profile changes, attributed to the user signing in, with the address if you enable IP capture.
- Plugin, theme and core updates, activations and deactivations.
- Settings changes, including the log's own settings.
- Media, taxonomy terms and comments.
- Events from other Dragon plugins, such as Login Security lockouts and Redirect Manager rule changes, when they are active.
Anything that looks like a secret (passwords, tokens, API keys, salts) is stored as redacted, so the log never becomes the thing that leaks.
Reading it under pressure
Filter by object type, event, severity and date, or search. Severity pills (info, notice, warning, critical) put the rows that matter at the top of your eye. The live updates toggle streams new events onto the first page, which is what you want open on a second screen during a deploy or a suspected intrusion.
In an incident the sequence is: find the first suspicious event, filter by that user, walk forward. A compromised account's trail usually reads: login from a new address, a plugin installed or a user created, then settings changed. Each row tells you what to undo.
Why "tamper-evident" is the part that matters
A log that sits in the same database as everything else can be edited by anyone who can edit the database, including the intruder. Dragon Activity Log seals every event into a hash chain: each entry carries a SHA-256 hash of the one before it. The Integrity tab verifies the whole chain and names the first entry that no longer matches if anything was altered or deleted directly in the database.
Two honest limits: a row deleted before it is sealed (sealing runs hourly, plus an end-of-request pass) leaves no trace, and someone with database write access who recomputes every later hash can hide an edit. That second gap is closed by the off-site anchor: on a schedule, the chain head (an event number and hash, never event data) is emailed to an address outside the site, or POSTed to a webhook you control, signed. Compare with an anchor later proves the chain up to that point is unchanged. Set the anchor email up now, to an address that is not on the site's own domain; it is one field.
Site Health shows an "Activity log integrity" test that goes red naming the first broken event, so you do not have to remember to check.
Retention and privacy
Set retention in days under Settings (0 keeps everything). Logged events can contain personal data, so decide deliberately: 90 days is common, a year for regulated sites. IP capture is optional and can be anonymised; if you trust proxy headers, list your proxies. The plugin integrates WordPress's privacy tools, so a user's export and erasure requests cover their events. Uninstalling keeps the log by default, because an audit trail you can lose by clicking uninstall is not much of an audit trail.
Going further: rollback, alerts and streaming
Dragon Activity Log Pro turns the log from evidence into a tool:
- Rich before and after diffs and one-click rollback of a content change to the state before any logged event.
- Security alerts for new-IP logins and bursts of failed logins.
- Streaming to Slack, a webhook or syslog, so the log also lives somewhere the intruder cannot reach.
- Sessions: who is logged in right now, with forced logout.
- Scheduled reports with CSV and JSON export, and WooCommerce order, product and setting events.
Streaming is the one to turn on first if you manage sites for clients: a copy of every event in your own Slack or log system is the difference between reconstructing an incident and guessing.
Pairs with
Securing the WordPress login covers the lockouts and second factors whose events land in this log, and the CRA checklist is where an audit trail becomes a requirement rather than a nice-to-have.