LAUNCH30 at checkout, until 30 November. See the pluginsSee plugins
View, manage, and debug WordPress cron jobs with ease. Features trash bin recovery, test mode, and execution logging.
Features
View, manage, and debug WordPress cron jobs. See all scheduled events, run them manually, and track execution history.
See all scheduled events with hook names, schedules, and next run times
Execute any cron job and automatically reschedule the next run
Run a cron without changing its schedule (perfect for debugging)
Deleted crons go to trash and can be restored for 30 days
Track when crons ran, how long they took, and any errors
Detect issues like disabled WP-Cron or overdue events
See all registered cron intervals
Accidentally deleted a cron? Restore it with one click. Other plugins delete permanently.
Run a cron without rescheduling. Great for debugging without disrupting schedules.
Every action button explains what it does on hover.
Clean, intuitive interface that matches WordPress admin styling.
Guides
Step-by-step guides from the team that builds it. All guides
Site health
How WP-Cron actually works, the four reasons scheduled tasks stop running, how to diagnose which one you have in a click, and how to replace the built-in scheduler with a real system cron.
Run leaves your existing booking in place when WordPress refuses the reschedule, and trash and log actions no longer report a failed save as a success. ## What's fixed in 1.0.10 - **"Run" no longer drops a recurring event.** When you ran an event and WordPress refused the new booking (for example a plugin blocking scheduling), the event was removed from the schedule while the message still said "rescheduled". The existing booking is now left untouched until the replacement is confirmed in the schedule, and the reason for a refusal is shown. - **Trashing an event is safe against a failed save.** The event is only unscheduled once its trash copy is confirmed saved, so a failed write can no longer remove an event that has no trash copy to restore. - **Trash actions report what really happened.** Restore, permanent delete and Empty trash now check that the change was saved and tell you when it was not, instead of claiming success. Restoring an event that is already scheduled is refused instead of booking it twice. - **"Clear logs" reports a database refusal** instead of saying the logs were cleared. - **Restoring a one-off event from the trash works again.** A trashed single event could not be restored whenever any other event shared its hook and arguments, even at a completely different time, and the screen then suggested permanently deleting it. WordPress allows several one-off events with the same hook at different times, so only a genuine second recurring booking is refused now. No settings, data or behaviour changes otherwise.
