Troubleshooting Chada Activity Monitor

This article covers the most common issues reported after installing or configuring Chada Activity Monitor.

No events are being logged at all

Most likely cause: the plugin is inactive, or all event groups have been disabled.

• Confirm the plugin is active under Plugins → Installed Plugins.
• Go to Activity Log → Settings → General and verify that at least one event group checkbox is ticked.
• Perform a test action — log out and log back in — and check whether an auth event appears. If it does, the plugin is working and the issue is that the action you were watching belongs to a disabled group.

The log shows no entries after filtering

Most likely cause: the active filters are too narrow, or no events match all selected criteria simultaneously.

• Click Reset in the filter bar to clear all filters and confirm that entries exist in the unfiltered log.
• Narrow down the filter by removing one criterion at a time until events reappear — this identifies which filter is excluding your expected results.
• Check that the date range includes the period when the events occurred. The log is ordered by most recent first, so if your date range is in the past, results will be there but may be on a later page.

License activation fails

Chada Activity Monitor contacts the license server at https://chadacreatives.com during activation. If activation fails:

• Confirm the key was copied in full — it should follow the format CAM-XXXX-XXXX-XXXX-XXXX (four groups of four alphanumeric characters after the CAM- prefix).
• Verify your server can reach https://chadacreatives.com over port 443. Some shared hosting environments block outbound HTTPS. Test with wp_remote_get('https://chadacreatives.com') from a mu-plugin.
• Check that your license has available activation slots. If all slots are used, deactivate the key on an unused site first (Activity Log → License → Deactivate).
• Confirm the subscription tied to the license is still active and has not expired or been cancelled.

Memory exhaustion under WP-CLI

There is a known issue where Chada Activity Monitor exhausts PHP memory when loaded under WP-CLI (includes/Licensing/License.php:31). Always pass --skip-plugins=chada-activity-monitor when running WP-CLI commands on a site where this plugin is installed:

wp post list --skip-plugins=chada-activity-monitor
wp eval-file my-script.php --skip-plugins=chada-activity-monitor

This is a known limitation in v0.1.0-dev and will be addressed in a future release.

Too many events / storage concerns

• Lower the Retention days value under Settings → General to reduce how long events are kept. The daily cron will prune old records automatically.
• Enable Log Archiving (premium) to preserve event history in compressed CSV files before records are pruned — this reduces database size while keeping an off-database record.
• Disable high-volume event groups you do not need — for example, the comments group on a high-traffic site can generate thousands of records per day.

IP address shows as anonymized unexpectedly

If IP addresses appear as x.x.x.xxx and you did not expect this, check Settings → Privacy → Anonymize IP — the toggle is on. This is intentional GDPR behaviour. If you need full IP addresses, toggle the setting off. Note that anonymisation applies only to new events; existing records cannot be de-anonymised.

Critical email alerts are not arriving

• Confirm Settings → Privacy → Email on Critical is toggled on.
• Check that Settings → General → Administration email address (admin_email) is set to an address you actively monitor.
• Check your spam or junk folder — the notification emails come from the WordPress default sender and may be filtered.
• If your server uses SMTP (via an SMTP plugin), confirm the SMTP connection is working. A broken SMTP configuration silently drops all WordPress emails.

Anomalies are not appearing (premium)

• Confirm you have an active premium license under Activity Log → License.
• Go to Settings → Anomaly Detection and verify that anomaly_enabled is toggled on.
• Remember that anomaly rules require specific event patterns to fire. The Failed login burst rule, for example, will not fire unless the configured number of failed logins occurs within the configured window. Trigger the condition deliberately in a test environment to confirm the rule is working.
• Check whether existing anomalies have already been acknowledged — acknowledged anomalies are removed from the unacknowledged count and may not be visible by default. Look for an “Include acknowledged” toggle on the Anomalies screen.

Slack notifications are not being delivered

• Click the Test button on the Slack settings tab. If the test message does not appear, the webhook URL is incorrect or your server cannot reach Slack’s API.
• Confirm the slack_min_severity setting is not set higher than the events you expect — if it is set to critical and only info events are occurring, nothing will be sent.
• If you have set the slack_groups filter, confirm the events you are watching belong to one of the listed groups.

Getting help

If none of the above resolves your issue, open a support ticket with the following information:

• Your WordPress version and PHP version.
• Your Chada Activity Monitor version (visible in Plugins → Installed Plugins).
• Your license key status (active / inactive / tier) from Activity Log → License.
• A description of the problem, including what you expected to happen and what happened instead.
• Any relevant entries from Tools → Site Health → Info → WordPress error log.