The WordPress change log that catches what hooks miss.

Tools → Change Ledger in the WordPress admin. A "Change Log" link also appears in the plugin's row on the Plugins screen.

hook — change was detected in real time by a WordPress hook.

cron — change was detected by the daily background check. This is the expected source for filesystem-level changes (FTP, SSH, deployment pipelines, hosting restores, etc.).

A cron-only entry for a change you expected to see as hook is a signal worth investigating.

If the entry is source: cron, the change happened outside WordPress. Common causes: a deployment pipeline that copies files directly, a hosting backup restore, a manual file edit over FTP/SSH, or a staging push.

If the entry is source: hook, the change went through WordPress. Check the user_login column and the WordPress admin action log if you have one.

Not in the current version. The plugin operates at the individual site level and stores data per-site. Multisite support (network admin view, network-level tracking) is planned for a future release.

All log data and snapshots are preserved. This is intentional — deactivating and reactivating should not destroy your history. Cron events are properly cleared on deactivation and rescheduled on reactivation.

Data is also preserved on deletion. A data management option (export, clear, selective delete) is planned for a future release. To clear manually: delete the {prefix}change_ledger_log table and the wp_change_ledger_* options from the database.

Configurable under Tools → Change Ledger → Settings. Default is 90 days. Set to 0 to keep entries indefinitely. Pruning runs automatically as part of the daily background check.

Yes. As long as your cron job calls wp cron event run --due-now (or hits wp-cron.php), the plugin's scheduled events will fire normally. The admin notice about cron health respects DISABLE_WP_CRON and will not nag you about timing — it will only alert if the events are not registered in WordPress at all.

Daily is the right default balance between coverage and performance. The wp_options table is not a queue — running snapshot diffs every few minutes on a large plugin list would add meaningful overhead. For most real-world debugging scenarios ("what changed this week?"), daily resolution is sufficient.

If you need sub-daily resolution for a specific investigation, you can trigger the cron events manually: wp cron event run wp_change_ledger_check_plugins.

If a plugin is installed and then deleted within a single day before the cron checker runs, the snapshots will match and no change will be recorded. This is an inherent limitation of the snapshot diffing approach. It is documented here so you can account for it — a clean log does not guarantee nothing happened within the last 24 hours.

This plugin is well-written, structured, and documented. If you need something beyond its scope, use it as a base — it's a faster start than building from scratch. Improvements and pull requests are welcome on GitHub.