WordPress Security Audit Log: Set Up and Read WP Activity Log

This article is a localized edition of the Japanese original. Read the Japanese original

An audit log records who did what on your site, when, and from where. When you suspect an unauthorized login or tampering, it gives you a way to trace back what changed and when. WordPress core has no audit log, so you record one with a plugin.

This article explains how to set up WP Activity Log, a widely used audit log plugin (formerly WP Security Audit Log; its slug in the official directory is wp-security-audit-log). Plugin details are as of November 2026. Screen labels are given as they appear in English.

What WP Activity Log records

The free version records the same range of events as the premium version. According to the official description, it mainly covers:

• Logins, logouts, failed logins and terminated sessions
• Changes to posts, pages, custom post types, categories, tags, widgets and menus
• User creation and deletion, and profile changes (password, email address, role)
• WordPress core updates and settings changes
• Installing, activating, updating and deleting plugins and themes
• Database table changes made by plugins, and files being added, modified or deleted

The premium version adds notifications by email and other channels, reports and exports, storing logs in an external database, forwarding logs to external services, managing logged-in users and their sessions, and detailed search filters. What you pay for is notification and analysis features, not a wider logging scope.

Another option is Simple History, which shows the change history in an easy-to-read form. The differences and how to use it are covered in How to log user activity in WordPress.

Step 1: Install the plugin

In the admin area, go to "Plugins" → "Add New Plugin," search for "WP Activity Log," then install and activate it. If you have WP-CLI, this command does the same thing:

wp plugin install wp-security-audit-log --activate

As of November 2026, WP Activity Log (the 5.7 line) requires WordPress 5.5 or later and PHP 7.4 or later. Logging starts with actions taken after activation.

Step 2: Go through the setup wizard

After activation, a setup wizard appears. (It also asks whether to allow sending diagnostic data; if you don't need that, choose not to send it.) In the wizard you choose the following:

You can change these choices later on the settings screen (Settings).

Step 3: View the log

A "WP Activity Log" item is added to the admin sidebar. Open "WP Activity Log" → "Log viewer" to see the recorded events listed newest first. Each row shows the date and time, user, IP address, event ID and a description.

An event ID is a number that identifies the type of event. Here are the ones you'll look at most during an investigation (IDs and names checked against the plugin's source code):

When you suspect unauthorized access, checking in this order makes the situation easier to understand:

1. Are there any 1000 events (successful logins) from IP addresses you don't recognize?
2. Is there a long run of 1002 and 1003 events (failed logins) from the same IP address?
3. Do 4000 (user created) or 4002 (role changed) events show administrators you didn't create?
4. Do 5000 and 5001 events (plugin installed or activated) show plugins you don't know?

Step 4: Choose which events to record

"WP Activity Log" → "Enable/Disable Events" lists the events that can be recorded. They're grouped by category; untick an event and save to stop recording it. You can also stop an event with the button that appears when you hover over its event ID in the Log viewer.

Recording fewer events slows the growth of the database, but keep the events for logins, users and plugins, because you'll need them in an investigation.

Step 5: Query the database directly

The log is stored in the same database as WordPress, in wp_wsal_occurrences (the events themselves) and wp_wsal_metadata (details for each event), assuming the table prefix is wp_. When you can't get into the admin area, or want to aggregate the data, you can read them directly with WP-CLI or phpMyAdmin. The date column created_on holds a UNIX timestamp (seconds).

# The 20 most recent failed logins (1002 and 1003)
wp db query "SELECT id, alert_id, FROM_UNIXTIME(created_on) AS created, username, client_ip FROM wp_wsal_occurrences WHERE alert_id IN (1002, 1003) ORDER BY created_on DESC LIMIT 20;"

# IP addresses with the most failed logins in the last day
wp db query "SELECT client_ip, COUNT(*) AS cnt FROM wp_wsal_occurrences WHERE alert_id IN (1002, 1003) AND created_on > UNIX_TIMESTAMP() - 86400 GROUP BY client_ip ORDER BY cnt DESC LIMIT 10;"

FROM_UNIXTIME() displays the date and time according to the database's time zone setting. Stick to read-only SELECT queries and don't modify the log tables directly.

Things to watch in operation

• Decide on a retention period. The longer you keep logs, the further back you can investigate, but the database grows. Decide based on the size of your site and your backup capacity.
• The log lives in the same database. If someone takes over an administrator account, they may delete or alter the log too. For important sites, keep web server access logs in a separate place, or consider storing or forwarding logs externally (premium features).
• Personal data. The log contains IP addresses and usernames. Decide why you record it and how long you keep it, and mention it in your privacy policy.
• Make a habit of reading the log. Recording isn't enough if nobody looks. Set a regular time, such as once a week, to check failed logins and user and plugin changes in the Log viewer.
• Harden the login too. If you see many failed logins, add attempt limits and two-factor authentication. See Protecting against brute-force attacks for how.

Summary

• Even the free version of WP Activity Log records changes to logins, posts, users, plugins, settings and more. Notifications, reports and external storage are premium features.
• In the wizard that appears after activation, choose the log detail level and retention period (3 months by default).
• Check the log in the "Log viewer" and use event IDs (1000 for logins, 1002 and 1003 for failed logins, 4000 for new users, and so on) to investigate.
• Choose which events to record in "Enable/Disable Events."
• The log is in the wp_wsal_occurrences table, and you can aggregate it with WP-CLI's wp db query.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)