WordPress Cron Missed Schedule: How to Diagnose Background Jobs

Why Background Jobs Fall Behind

WordPress uses WP-Cron to run scheduled work such as update checks, scheduled posts, cleanup tasks, plugin queues, and time-based publishing. Unlike a system cron daemon, WP-Cron is normally triggered by site requests. If the site receives little traffic, blocks loopback requests, or disables WP-Cron without replacing it, scheduled work can run late.

That delay can be easy to miss because the homepage may still load. The symptoms usually show up somewhere else: queued emails, stale reports, late product syncs, expired transients that never clear, WooCommerce actions that remain pending, or scheduled content that publishes long after the intended time.

Confirm the Cron Symptom

• Scheduled posts publish late or stay scheduled after their publish time.
• WooCommerce Status > Scheduled Actions shows a growing set of pending, failed, or past-due actions.
• Site Health reports a scheduled event problem, loopback request problem, or HTTP request problem.
• Emails, imports, reports, backups, or product feeds run only after someone visits wp-admin.
• A staging, low-traffic, password-protected, or heavily cached site shows the issue more often than production.

Check Site Health and Loopbacks

1. Open Tools > Site Health and review scheduled event, loopback, REST API, and HTTP request warnings.
2. Check whether the site can request its own HTTPS URL without authentication, firewall, maintenance-mode, or WAF blocks.
3. Confirm wp-cron.php is not blocked by robots, basic auth, host security rules, CDN rules, or an overbroad security plugin rule.
4. Review PHP timeout, memory, worker, and database warnings if jobs start but do not finish.
5. Look at the last plugin, theme, PHP, cache, security, or hosting change before the timing problem appeared.

Loopback failure is not always the root cause, but it is an important signal. A site that cannot call itself reliably may also struggle with background processing, update checks, and queue runners that depend on internal requests.

Review WP-Cron and Server Cron

1. Check wp-config.php for DISABLE_WP_CRON and document whether it is true or false.
2. If WP-Cron is disabled, verify the host or server cron calls wp-cron.php on the intended interval.
3. If traffic is low or irregular, consider replacing request-triggered cron with a real server cron after confirming host guidance.
4. If the site is protected by staging passwords or IP rules, make sure the cron runner can reach the site.
5. After changing cron behavior, wait for a due event and verify that the queue age decreases.

Do not enable both a high-frequency external runner and a poorly configured plugin runner without understanding the queue. Duplicate runners can make noisy jobs worse, while no runner leaves due work waiting for the next page load.

Review WooCommerce Action Scheduler

WooCommerce and many extensions use Action Scheduler for background queues such as payment processing, webhooks, subscriptions, order notifications, scheduled sale work, and extension cleanup. Action Scheduler gives you more evidence than plain WP-Cron because you can inspect hook names, statuses, logs, attempts, and scheduled times.

1. Open WooCommerce > Status > Scheduled Actions and filter by Failed, Pending, and Past-due actions.
2. Group repeated failures by hook name so you can identify the owning extension.
3. Read log messages before clicking Run, Cancel, or Delete.
4. Check whether one slow callback, external API timeout, or missing plugin class is blocking repeated batches.
5. For payment, subscription, or webhook actions, test on staging before clearing jobs that may represent real customer work.

Common Root Causes

• Low traffic: due events wait because no request triggers WP-Cron at the scheduled time.
• Disabled WP-Cron: DISABLE_WP_CRON is true but the replacement server cron is missing, broken, or pointed at the wrong path.
• Blocked loopbacks: security, firewall, CDN, basic auth, or maintenance rules stop internal requests.
• Hosting pressure: PHP workers, memory, max execution time, database load, or object cache issues slow queue processing.
• Failing callbacks: a plugin hook throws errors, times out, or calls an unavailable external service.
• Runaway scheduling: a plugin creates more recurring jobs than the site can complete.

A useful fix should name the owner of the failure. Server cron setup belongs to hosting or operations. A failed payment webhook callback belongs to the commerce extension or gateway. A blocked loopback may belong to the firewall, CDN, or security plugin. Keeping those owners separate prevents broad plugin deactivation from becoming the default response.

How WPlura Helps

Web Plura Diagnostics is relevant here because its free local checks include Site Health-style signals, hosting constraints, Cron and Background Jobs checks, Action Scheduler presence, WooCommerce queue backlog signals, front-end response, Fix First prioritization, WP-CLI output, and support-safe JSON/CSV exports. It does not repair cron automatically. It helps you capture the evidence needed to decide whether the next action belongs to a site admin, developer, host, or plugin vendor.

Verify the Repair

1. Trigger or wait for one known due event and confirm it runs near the expected time.
2. Check Site Health again for scheduled event and loopback warnings.
3. Confirm Action Scheduler pending and failed counts stop growing after the fix.
4. Review server or application logs for the same hook after one full recurrence interval.
5. Record the final owner, change made, rollback option, and before/after queue state.

For a durable check, compare the same hook after one normal recurrence interval, not only after a manual run. A queue that clears once but immediately refills usually points to a failing callback, an external API timeout, or a runner that is too slow for the amount of scheduled work.

Prevent Repeat Cron Backlogs

• Use a documented server cron on low-traffic, staging, private, or heavily cached sites.
• Keep a short change log for cron, cache, security, firewall, CDN, PHP, and hosting changes.
• Review Action Scheduler after imports, sales campaigns, subscription renewals, and major plugin updates.
• Avoid scheduling recurring jobs on every page load; plugins should check whether a hook is already scheduled.
• Keep diagnostic exports with maintenance notes so the next support handoff starts with evidence.

The goal is not to make every action run at the exact second. The goal is to make important background work predictable enough that publishing, payment, email, sync, and cleanup workflows do not silently drift for hours or days.

Related WPlura Plugin Help

After you capture the delayed hook, queue status, and Site Health warnings, use Web Plura Diagnostics to collect a local snapshot of cron pressure, hosting limits, front-end response, plugin/theme impact, and support-safe evidence. Start with the free WordPress.org plugin download: download the free plugin on WordPress.org. For broader connected reporting, history, alerts, and portfolio oversight, review the Pro path here: WPlura Pro purchase and private download. Product details are available at WPlura product details.

1. Run a local diagnostics scan before changing cron behavior again.
2. Review Cron and Background Jobs, hosting, front-end response, Site Health, and plugin/theme impact findings.
3. Export a support-safe JSON or CSV snapshot when the host or developer needs the same facts.
4. Make one owner-specific change, then rerun the same diagnostics and compare the queue state.

References

Frequently Asked Questions