Updated on 16 April, 2026
WP Activity Log plugin & activity log database documentation
WP Activity Log stores activity data in its own tables within the WordPress database by default.
Upgrade to the Enterprise edition to store logs in an external database, send them to a SIEM, or archive them externally for long-term retention.
This knowledge base entry explains how the activity log data is stored in the database.
Table of contents
WP Activity Log database tables structure & documentation
WP Activity Log creates six tables in the WordPress database. It uses these tables to store the activity log and the plugin’s settings. This KB article lists each table and its structure.
Note: The wp_ prefix is the default WordPress database prefix. If you have changed yours, the plugin’s table will use your configured prefix.
Table: wp_wsal_custom_notifications
The plugin saves definitions for Custom Notifications in this table, including who to notify, which channels, notification triggers, and message templates. This table has the following columns:
| Column name | Type | Description |
|---|---|---|
| id | int | A unique ID for the notification |
| notification_user_id | int | The WordPress user ID of the notification creator/owner |
| notification_username | varchar | The WordPress username of the notification creator/owner |
| notification_settings | json | Specifies whether to send |
| notification_title | varchar | Human-readable notification title |
| notification_email | varchar/text | A comma-separated list of email recipients |
| notification_email_bcc | varchar/text | A comma-separated list of BCC email recipients |
| notification_email_user | tinyint(1) | A boolean-like value specifiying whether to email the affected WordPress user |
| notification_phone | varchar/text | |
| notification_template | json | The subject and body template of the email notification (with placeholder support) |
| notification_sms_template | json | The SMS notification template (with placeholder support) |
| notification_slack | varchar/text | The Slack webhook URL or channel identifier destination |
| notification_slack_template | json | The Slack message template (with placeholder support) |
| notification_query | json | The notification query triggers used to trigger the notification |
| notification_query_sql | text | The SQL equivalent of the notification query triggers |
| notification_status | tinyint(1) | Details whether the notification is enabled (1) or disabled (0) |
| notification_view_state | tinyint(1) | The view state of the notification in the UI |
| created_on | int | The UNIX epoch of when the notification was created |
Table: wp_wsal_generated_reports
The plugin stores generated reports metadata in this table, including who created the report, filters used, output format, and processing state, among other data. This table has the following columns:
| Column name | Type | Description |
|---|---|---|
| id | int | A unique ID for the report |
| generated_report_user_id | int | The WordPress user ID of the user who requested the report |
| generated_report_username | varchar | The WordPress username of the user who requested the report |
| generated_report_filters | json | The report filters (date range, users, alert IDs, etc) |
| generated_report_filters_normalized | json | Normalized/flattened subset of report filters |
| generated_report_header_columns | json | Human-readable report headers |
| generated_report_where_clause | text | SQL WHERE clause string precompiled from the filters |
| generated_report_finished | tinyint(1) | Report status – 0 while generating, 1 when finished |
| generated_report_to_date | float/decimal | UTC epoch in seconds marking the “to” boundary of the report period |
| generated_report_name | varchar | Internal name of the report |
| generated_report_file | varchar | Filename of the generated artifact (such as CSV or HTML) |
| generated_report_tag | varchar | Optional tag label |
| generated_report_format | tinyint/smallint | Output format code (such as CSV or HTML) |
| generated_report_number_of_records | int | Report row count |
| created_on | int | The UNIX epoch of when the notification was created |
Table: wp_wsal_metadata
Table structure
The plugin saves the metadata of each event in this table. Metadata includes data such as post titles, post URLs, order status, SKUs, etc. This table has the following columns:
| Column name | Type | Description |
|---|---|---|
| id | bigint | A unique ID that is assigned to every row in the table |
| occurrence_id | bigint | The ID that correlates the metadata in this table to the alert ID stored in the wp_wsal_occurrences table |
| name | varchar | The name of the row that describes the data stored in that row |
| value | longtext | The actual metadata value, such as post title, URL, etc |
You can view event metadata through the Event data inspector by clicking on the More details… button in the Log Viewer. Learn more about WordPress activity log data and metadata.
Table: wp_wsal_occurrences
The plugin saves the event data in this table. Each row represents a single activity log event that occurred on the WordPress website, as seen in the Log Viewer. This table has the following columns:
| Column name | Type | Description |
|---|---|---|
| id | bigint | A unique ID is assigned to every row in the table |
| site_id | bigint | The ID of the website in a WordPress multisite network (in non-multisite environments, this is set to 1) |
| alert_id | bigint | The ID of the event in the activity log |
| created_on | double | The date and time in Unix time of when the change happened |
| client_ip | varchar | The IP address of the entity actioning the activity |
| severity | varchar | The severity measures the potential impact of the recorded activity |
| object | varchar | The object of the activity |
| event_type | varchar | The type of activity that took place |
| user_agent | varchar | The browser user agent |
| user_roles | varchar | The role of the user actioning the activity |
| username | varchar | The WordPress username of the user that actioned the activity |
| user_id | bigint | The ID of the WordPress user |
| session_id | varchar | The ID of the session during which the activity took place |
| post_status | varchar | If the activity concerns a post, the post status (published, draft, future, pending, etc) is recorded here |
| post_type | varchar | The type of post (such as post, custom post type, or page) |
| post_id | bigint | The unique WordPress ID of that post |
Table: wp_wsal_periodic_reports
The plugin stores periodic reports metadata in this table, including who created the report, filters used, and processing state, among other data. This table has the following columns:
| Column name | Type | Description |
|---|---|---|
| id | int | A unique ID for the periodic report |
| report_user_id | int | The WordPress user ID of the user who created the report |
| report_username | varchar | The denormalized WordPress username of the user who created the report |
| report_name | varchar | Human-readable report name |
| report_frequency | tinyint/smallint | Internal code representing report frequency |
| report_format | tinyint/smallint | Internal code representing export format |
| report_email | varchar/text | A comma-separated list of email recipients |
| report_data | json | Report’s filters |
| report_tag | varchar | Optional tag label |
| report_disabled | tinyint(1) | Details whether the report is enabled (1) or disabled (0) |
| last_sent | int | The UNIX epoch of when the report was last sent (0 means never sent) |
| created_on | int | The UNIX epoch of when the report was created |
Table: wp_wsal_sessions
The plugin saves users’ session data in this table. Whenever someone logs in to the WordPress website, the plugin keeps a record of this login. When the user logs out, that session data is deleted from the table. As such, in this table, you can see who is logged in to your website at any point in time. The plugin uses this data for the WordPress users’ session management features, such termination of idle WordPress users’ sessions. This table has the following columns:
[table “xl” not found /]Examples of how WordPress activity log data is stored in the database
The wp_wsal_occurences table holds the data that we can see in the Log Viewer. The default view does not show all data. However, you can click the More details… button to view all information pertaining to a single event (including metadata as discussed in the previous section).
In the next sections, we will look at a couple of examples to showcase actual WordPress activity data as it is stored in the wp_wsal_occurences table.
User login
In this example, we can see an administrator with the username ‘joel’ logging in from a local machine. The alert ID is 1000, which can be cross-referenced with the list of activity log event IDs. The created_on shows us a Unix timestamp of 1690899814.031139, which tells us that the event happened on Tuesday, the 1st of August 2023, at 4:23:34.031 PM.
Plugin installation
In the example below, we see the same user (he likes to keep himself busy) installing a plugin. We know this because the alert ID is listed as 5000.
We can cross-reference this with wp_wsal_metadata table by looking for entries where the occurrence_id field in wp_wsal_metadata matches the id in wp_wsal_occurrences. This tells us that the user installed the CAPTCHA 4WP plugin.
Using the activity log viewer
Use the log viewer to see all the events in the WordPress activity log. When you open the viewer, the plugin retrieves the metadata and event IDs from the WordPress database and uses this data to show the events, as shown in the below screenshot.
To keep database access to a minimum, the plugin only retrieves the data it needs for that view.
Integrating the activity logs with your central logging system
WP Activity Log plugin has out-of-the-box support for mirroring the activity log to Log Management Services such as AWS, CloudWatch, and Loggly. However, if you use a service that we do not support, you can easily integrate the WordPress activity log with your logs management system of choice using the information provided in this document. All you need to do is allow access to the database where the logs are and configure MySQL connectors to read the data.
Alternatively, you can mirror the WordPress website activity log to a log file and configure your logs management system to read directly from the log file.
