A post is due at 9:00, but at 9:20 it still has not appeared. That is an example of the symptom, not a diagnosis. Changing a cron setting straight away can leave you with a second problem and less evidence of the first.
Start by recording the expected publication time, the post’s current status and the time zone shown in Settings → General. Keep the post ID and a screenshot of its schedule. A time entered in one zone and checked in another can look like a delay; changing the site-wide time zone before understanding that difference can affect other work. See WordPress’s General Settings documentation.
Find out what is supposed to trigger the work
WordPress normally checks scheduled work during page requests. It does not behave like a system scheduler that wakes at a precise wall-clock time. Low traffic can therefore delay a due task. A site may instead use a hosting or system job to trigger WordPress, so establish which arrangement is actually in use. The WP-Cron overview explains the default mechanism.
Visitor analytics alone will not settle this. A cached response can reach a visitor without making the same request to WordPress. Treat that as a question for the hosting configuration, rather than proof that every recorded visit checked the schedule.
If there is an external job, record its owner, command or endpoint, target installation and recent execution history. Check the associated WordPress configuration too. DISABLE_WP_CRON being enabled can be intentional when an external trigger is in place. Do not remove it merely because a post is late, or enable it before a replacement trigger exists. WordPress documents that setup in its system scheduler guide.
Inspect the queue without replaying everything
For an operator with authorised shell access, this WP-CLI command lists scheduled events:
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence --format=table
Run it against the intended installation; a multisite network also needs the correct site context. Compare the GMT field with the expected time after accounting for the site’s zone. These are documented fields in wp cron event list.
The queue tells you what is scheduled. It does not prove that a callback completed its work. Keep the output private if hook names or operational details should not be public, and do not paste a whole production log into a community post.
Separate a trigger problem from a completion problem
wp cron test checks the spawning mechanism and attempts an HTTP spawn. It is an active diagnostic, so assess the effect of triggering pending work before using it on a live site. An intentionally configured external scheduler can also explain a complaint about disabled WP-Cron. A successful test does not certify every plugin job or business workflow. The distinction matters when interpreting the command’s documented checks.
If the trigger appears to work, investigate the affected job: relevant errors, recent plugin changes, timeouts and the expected result. A backup starting is different from a usable backup finishing. A mail job running is different from a message arriving. Avoid replaying all due events as an exploratory shortcut; some callbacks send messages or change stored data.
Verify the repair against the original symptom
Agree on a small, authorised test, such as a test post scheduled for a future time. Observe its status and public availability under the intended trigger arrangement. Record any manual trigger used during the test: that intervention changes what the result demonstrates.
Leave a handover note with the trigger owner, schedule, log location, test time and observed outcome. For WPShieldPro, this is a useful way to document WordPress maintenance and troubleshooting work: make the result understandable to the next person responsible for the site.
Disclosure: this article was prepared with AI assistance. The 9:00/9:20 example is hypothetical. Commands are documentation examples, not results from a customer system.
Top comments (0)