WP-CLI can list scheduled WordPress events so you can see their hook names, next run times and recurrence. Begin with read-only inspection and distinguish it from running or deleting events, which can trigger business actions or remove necessary work.
IN THIS ARTICLE
01 Confirm the installation
Use the correct hosting account and WordPress path. On Multisite, select the intended site URL as required. Verify the site identity before using any command that changes data.
The following path and URL are placeholders. Replace both with the installation directory and intended site URL confirmed for your service. In Multisite, the URL selects the subsite whose cron configuration is being inspected.
02 List the schedule
wp cron event list --path=/path/to/wordpress --url=https://example.com --fields=hook,next_run_gmt,next_run_relative,recurrence
Read times in the displayed timezone and compare them with the current time. A hook name often suggests its owning plugin, but verify ownership before acting. Avoid including event arguments in a shared report unless needed, because they may contain private values.
03 Test the spawning model carefully
wp cron test --path=/path/to/wordpress --url=https://example.com
This tests the normal spawning mechanism and may attempt to spawn WP-Cron, so it is not merely a static configuration read. It can report an error when DISABLE_WP_CRON is intentionally set for an external scheduler. In that arrangement, inspect the external job rather than assuming the constant is wrong.
04 Investigate overdue events
- Record the overdue hook, due time and owning component.
- Review the runner configuration and recent PHP errors.
- Check whether other hooks are also overdue or only one component is failing.
- Use the component's documented recovery process if an event needs to be retried.
- Recheck the listing after the next expected interval.
Why should I avoid running every due cron event at once?
Running every event immediately can send email, process subscriptions, publish content or contact external services. Deleting events can stop required work, and a plugin may recreate them in an unexpected state. Do not use those actions simply to make an overdue list disappear.
WooCommerce and other applications may maintain their own action queues in addition to core cron events. A healthy core listing does not guarantee every application job completed.
When reporting a problem, share the relevant hook names, times and sanitised errors together with the scheduler arrangement. Keep credentials and private event arguments out of the report, and verify the actual business outcome after the scheduling issue is corrected.