Run history
Every WP-Cron event with its status, duration, memory added, query count, callback count, warnings and fatal errors, and a sparkline of recent runs per hook.
v1.5.6Cron Monitor
WordPress ships no cron log. The schedule is a list of hook names and timestamps, and once an event fires, nothing is written down. This writes the record WordPress does not.
What it does
It records every scheduled event as it runs, not just what is scheduled. That is why a cron job that runs twice, dies halfway, or silently stops is so hard to pin on anything.
Owner attribution
The plugin, theme, mu-plugin or core file behind every callback, resolved by reflection while the event is actually running rather than guessed from the hook name.
Orphan verdicts with evidence
The difference between "zero callbacks observed across fourteen runs, safe to delete" and "callbacks observed during cron, do not delete". A verdict you can act on rather than a guess.
Duplicate detection
Same hook, same arguments, same schedule, found and removable, with a dry run before anything is deleted and an optional per-event guard that rejects duplicate schedules at source.
Cron Health
A ranked list of what to fix: lock starvation diagnosis, cron option size, a loopback check of your own wp-cron.php, a stall check, and a recommended WP_CRON_LOCK_TIMEOUT.
Who spends your cron budget
Seven days of cron time attributed to the plugin that spent it, which is usually the fastest way to find out why the site slows down on a schedule.
Manage events
Add, edit, run, delete and pause scheduled events, including pausing a hook without deactivating the plugin that owns it. Custom recurring schedules, with a guard that refuses to delete one an event still uses.
Alerts, off by default
Email and webhook alerts for fatal errors, killed runs, drift, starvation, and for events that have simply stopped running. Slack and Discord work with no intermediary.
What gets recorded, per run
These are the fields written for every event that fires, the actual shape of the data behind the Run History screen.
status
Completed, killed, or finished with a fatal error.
duration
How long the event took from start to finish.
memory_added
Memory the run added, rather than total process memory.
query_count
Database queries made during the run.
callbacks
How many callbacks were listening, and which file and plugin owns each one.
warnings
PHP warnings and notices raised while the event ran.
notes
Anything your own callbacks attach through the plugin's logging hook.
Screenshots
Straight from the WordPress.org listing, so what you see here is what the plugin actually renders.
Requirements and fine print
Unlike the others, this one does not need WooCommerce. It uses it only if it is there, to log Action Scheduler failures.
wordpress
6.5 or higher, tested up to 7.1.2.
php
8.1 or higher.
woocommerce
Optional. Where present, Action Scheduler failures are logged, failures only by default.
licence
GPLv2 or later.
0.00Price, now and later
0.00Fee per sale
GPLv2Licence, or later
noneTelemetry, ever