A scheduled WordPress post that stays stuck on “Missed schedule” is usually a symptom, not the whole problem. The same scheduling system may also run backups, email digests, cache cleanup, subscription renewals and plugin maintenance. This guide explains WP-Cron and gives you a safe order for troubleshooting it.

What WP-Cron actually does

WordPress does not run a traditional always-on scheduler by default. According to the official Plugin Handbook, WP-Cron checks the list of due tasks when the site receives a page load. If traffic is very low, a task may run late. If loopback requests fail, it may not run at all.

That design is convenient because it works on common hosting without server access. It is not exact to the second, and it can be unreliable on a quiet site or a site with a broken internal HTTP request.

Common signs of a WP-Cron problem

  • Scheduled posts show “Missed schedule.”
  • Automated backups stop arriving.
  • WooCommerce or membership tasks remain pending.
  • Scheduled emails are late.
  • Old transients or cache files are not cleaned.
  • Site Health reports a scheduled-event or loopback error.

Step 1: Back up before changing anything

Create a current file and database backup. Cron troubleshooting may involve plugins, configuration and server tasks; a rollback point keeps a small mistake from becoming an outage. Use SiteChai’s WordPress backup guide if you need a checklist.

Step 2: Check the obvious configuration

Confirm the site timezone under Settings → General, then check that the post was scheduled for the intended date. Next inspect wp-config.php for this line:

define( 'DISABLE_WP_CRON', true );

If it exists, WordPress’s page-load trigger is disabled. That can be correct only when a real server cron calls wp-cron.php. Do not simply remove or add the line until you know which scheduling method the site uses.

Step 3: Use Site Health

Open Tools → Site Health and review critical issues. Pay attention to loopback-request failures, REST API errors and scheduled-event warnings. A security plugin, maintenance mode, DNS error, expired SSL certificate or host firewall can stop the site from calling itself.

Copy the exact error and timestamp before testing. Vague “cron is broken” reports are much harder to investigate than a repeatable loopback or HTTP response.

Step 4: Find overdue events

WP-CLI can test the spawning system and list scheduled events:

wp cron test
wp cron event list

Run CLI commands only when you understand the environment or have a backup. The official WP-CLI documentation also supports running a due event manually. Do not repeatedly run unknown plugin hooks on a live store; a payment, email or renewal task may not be safe to duplicate.

Step 5: Isolate plugin or theme conflicts safely

Use a staging site when possible. Temporarily deactivate recently added scheduling, security, cache or maintenance plugins one at a time, then test again. If the problem began after an update, check the plugin’s release notes and support channel.

SiteChai’s WordPress staging guide explains how to test changes without experimenting on visitors.

Step 6: Use a real server cron for predictable timing

For low-traffic sites or important store tasks, a system scheduler is more dependable. A common pattern is:

  1. Set DISABLE_WP_CRON to true.
  2. Create a server cron that requests or runs wp-cron.php every five or ten minutes.
  3. Verify that it receives a successful response and that scheduled events move forward.

The exact command depends on the hosting control panel, PHP path and security configuration. Do not copy a command from another server blindly. If you host with SiteChai, use the official support channel to confirm the correct command and interval for your plan.

What not to do

  • Do not hit wp-cron.php every minute without checking server limits.
  • Do not run every overdue event repeatedly.
  • Do not edit WordPress core files.
  • Do not disable security tools permanently just to make the warning disappear.
  • Do not assume a scheduling plugin caused the issue; the failure may be DNS, SSL or loopback related.

After the fix

Schedule a harmless test post a few minutes ahead, confirm it publishes, then check the next-run time for important plugin events. Monitor backups, emails and store actions for at least one full cycle. Document the final cron method so a future administrator does not accidentally enable two schedulers.

Frequently asked questions

Why does WP-Cron need visitors?

By default, WordPress checks for due events during page loads. A quiet site may therefore run an event late.

Is it safe to disable WP-Cron?

Only when a working server cron replaces it. Disabling the built-in trigger without a replacement can stop scheduled tasks.

How often should a server cron run?

Five to fifteen minutes is common, but the right interval depends on the site and hosting limits. Stores with time-sensitive queues may need a different design.

Can cron failures slow down WordPress?

Yes. A large queue, repeated failed requests or badly written tasks can add load. Identify the hook and underlying cause rather than only clearing the queue.

References: WordPress Cron handbook and official WP-CLI cron commands.