When a WordPress cron job is not running, separate three questions: is the event scheduled, is a runner starting it, and does its callback finish successfully? A missed scheduled post and a failed backup can share a runner problem, but a single broken plugin task can fail while the rest of cron works.
WP-Cron is not a continuously running system scheduler. WordPress normally checks scheduled work during page loads. A quiet site, cached traffic that never reaches WordPress, or a blocked loopback request can delay execution. The WordPress cron handbook explains that trigger model.
Inspect Before Running Anything
Record the affected task, expected time, site timezone, and last confirmed result. If a scheduled post is late, note the post ID and publication time. If a backup is missing, record the backup job reference and archive timestamp. These are better evidence than a dashboard warning alone.
With authorized SSH access, run this from the correct WordPress installation:
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence
wp option get timezone_string
wp option get gmt_offset
The event-list command is an inventory, not proof of completion. Confirm the hook belongs to the affected feature. If there is no matching event, investigate registration or the plugin's own queue rather than repeatedly triggering cron.
Find the Runner
Ask the host whether the site uses normal WP-Cron or a server-managed schedule. Inspect the relevant configuration and host job history. If DISABLE_WP_CRON is enabled, verify that the replacement runner actually exists, targets this installation, and runs under an account with the required access.
Do not disable WP-Cron simply because a tutorial recommends system cron. First establish the replacement and observe it working. A schedule copied from another server can have the wrong PHP binary, path, account, or environment.
For HTTP-triggered failures, follow the loopback diagnostic guide. Check authentication challenges, certificate errors, DNS resolution, and firewall logs from the server's perspective. A successful homepage visit on your laptop proves a different route.
Verification record for WordPress Cron Job Not Running: Find the Missing Trigger or Failed Task. Fill in your own evidence.
Test One Harmless Task
Use a private staging copy with outgoing mail, payment actions, and integrations isolated. Choose one known task whose side effects you understand. A developer can invoke that specific hook while observing private application logs and the expected result.
Avoid running every overdue event on production as a first test. A backlog can contain reminders, imports, deletions, or payment-related actions. Review the queue owner and replay semantics before releasing it.
If one callback fails, capture its error and dependency. The runner might be healthy while a plugin lacks a credential or encounters incompatible code. For WooCommerce queues, use the separate Action Scheduler backlog guide; its action records provide a different level of evidence.
Prove the Fix Without Manual Intervention
Watch at least two future intervals for the chosen task. Record scheduled time, runner start, completion, and user-visible result. Confirm a test post publishes at the expected local time or a new backup archive is retrievable.
Retain a monitor for overdue work with an accountable recipient. Checking that a manual command succeeded once will miss the next disabled runner. For an unresolved production backlog, request a scoped cron investigation with task names and sanitized timestamps, not an unrestricted export of customer jobs.
References checked September 29, 2026. Diagrams and examples are explanatory, not measured customer results.