See, run, and debug everything WP-Cron is doing - with a doctor that tells you why it's stuck, not just that it is.
The dashboard
Tools → Cron Manager lists every scheduled event: hook, schedule, next run, arguments. Per event:
- Run - execute now and reschedule the next run. The existing booking is not removed until the new one is confirmed in the schedule; if WordPress refuses the new booking, the existing one is left in place and the reason is shown. A one-time event is removed from the schedule when you run it (as WP-Cron does), so it does not run a second time; Test keeps it. Events WordPress core schedules itself are protected from the trash; plugin events are not, even when their names start with
wp_. - Test - execute without touching the schedule (safe for debugging).
- Trash - deleted events go to a 30-day trash and can be restored. Restore puts the event back at its own time: a one-time event at its scheduled time if that is still ahead (otherwise a minute from now), a recurring event on its original schedule (the next run on the same rhythm). An event that was already overdue when you trashed it runs a minute after Restore, so its pending run is not skipped. The message says when it runs next.
Run, Test and Trash match an event's hook name exactly as it is stored in the schedule (mixed case, dots, slashes, backslashes, colons, repeated spaces, percent sequences, angle brackets and non-Latin text included), together with its arguments.
The Run Log tab records when events ran, how long they took, and errors. Times are shown in your site's time zone. Schedules lists every registered interval.
Add Event
The Add Event button on the dashboard schedules a brand-new cron event without touching code: give it a hook name, a schedule (single or recurring), a first-run time, and optional arguments as a JSON list such as [5, "abc"] (a JSON object is refused: WordPress would pass its keys as named arguments). The first-run time is read in your site's time zone (shown next to the field), not your browser's. On multisite, adding an event needs a network administrator (the manage_network_options capability).
Real-tick logging
The Run Log now records automatic WP-Cron runs as they happen - with duration and success/failure - not just manual Run Now and Test runs. A Source column marks each entry Automatic or Manual, and the cron doctor's "last activity" counts automatic runs only, not Run or Test clicks. Events a server cron runs with WP-CLI (wp cron event run --due-now) are logged the same way. With ALTERNATE_WP_CRON, runs started by any page load, wp-admin included, are logged too.
The cron doctor
When something's overdue, press Diagnose in the health bar. It runs a live root-cause check:
- DISABLE_WP_CRON set but tasks overdue → your server cron isn't firing; the diagnosis includes the exact crontab line to add.
- Site can't reach its own wp-cron.php → you see the exact loopback error (basic auth, firewall, DNS…). A failing loopback is reported whenever WP-Cron depends on it, even before tasks are late. A wp-cron.php that answers with a redirect counts as a failure, with the address it redirects to: WP-Cron does not follow redirects. Sites using
ALTERNATE_WP_CRON(which runs cron during page loads, not through the loopback) are not blamed on the loopback. - A crashed run holding the lock → points you at the log to find the fatal task.
- Everything works but the queue is starved → the low-traffic-site case; the diagnosis confirms the site can reach its own wp-cron.php (it does not run the queue itself: overdue tasks run on the next visit, or use Run on one), and recommends a server cron.
Data & privacy
The execution log lives in your database; a daily cleanup deletes entries older than 7 days, measured in your site's time zone (change it with wp option update dragoncronmanager_log_retention_days <days>). Uninstalling keeps data by default (opt-in delete: wp option update dragoncronmanager_delete_data_on_uninstall 1).