Synthetic Industry

Troubleshooting guide · updated 2026-10-11

Scheduled WordPress posts and tasks running late: how WP-Cron decides and why it misses

What the built-in scheduler does on each page load, the causes of missed schedules, how a real scheduler replaces it, and how to read the event list.

WordPress has no clock, only a to-do list checked by visitors

The plugin handbook says WP-Cron looks through its list of scheduled tasks on every page load and runs any that are due during that load. It is named after the UNIX scheduler but does not run continuously: it is triggered only when someone requests a page. Its own example is a task set for 2:00pm on a site nobody visits until 5:00pm, which runs at 5:00pm. WordPress core uses the same mechanism for update checks and for publishing scheduled posts, so a quiet site can show "Missed schedule" simply because nobody arrived at the right time. A system scheduler would skip a missed time; WP-Cron instead keeps the task queued and runs it at the next opportunity.

  • Late is the normal failure on a quiet site; never is a sign of a blocked or disabled trigger.
  • You cannot know exactly when a task will run, only that it will run eventually.

Five causes worth checking in this order

First check whether the site's configuration file sets DISABLE_WP_CRON to true. That switch turns the built-in scheduler off and is only safe when a real scheduled job calls the site in its place; if it was set by a former developer and the job was never created, nothing scheduled will ever run. Second, look at caches: one membership vendor says heavily cached sites may not trigger WP Cron. Third, consider the host, because some hosts restrict a site requesting its own address. Fourth, look for a task that errors every time it runs and so never completes. Fifth, consider ALTERNATE_WP_CRON, which the configuration handbook says is most commonly used when scheduled posts are not getting published as predicted; it works by redirecting the visitor's browser and the handbook warns of risk because it depends on a non-native service.

  • Search the configuration file for DISABLE_WP_CRON and for ALTERNATE_WP_CRON.
  • Ask the host whether loopback requests from the site to itself are allowed.
  • Note any task whose next-run time keeps moving forward without it ever completing.

Replacing the visit trigger with a real scheduler

The handbook's documented fix for tasks that must run on time is to have the operating system's scheduler request wp-cron.php, then add the DISABLE_WP_CRON line so WordPress stops running cron on every page load, which it says is no longer necessary once a scheduler does the job and adds to resource usage. Its examples request wp-cron.php with wget or PowerShell, and it recommends no particular frequency; you choose the interval. The two changes belong together: switching the built-in trigger off without the real job in place stops everything scheduled. Adding the job without the switch leaves WordPress also running cron on each page load; this guide's own reading, not the handbook's, is that due tasks may then be started by both routes, so make the second change at the same time.

  • Pick an interval that matches your tightest schedule.
  • An outside scheduler that requests the address on a timer also works where the host offers no cron.
  • Make both changes in one maintenance window, with a note of how to reverse them.

Proving the trigger with a harmless test event, not a public post

A scheduled post proves the trigger only by publishing, which you do not want on a live site just to test. A one-off event does the same job with no public effect. WP-CLI's cron event schedule command schedules an event for a hook name you choose at a time you choose (a timestamp or text that strtotime accepts; the default is now), and the WP Crontrol plugin has an add-event screen. If nothing on the site listens to the hook name, running the event does nothing: WP Crontrol describes an event with no action as having no functionality that will be triggered when it runs. WordPress's own cron file reschedules a due event if it recurs, removes its entry from the schedule and then fires its hook, so a one-off event drops out of the event list once it has run, and one that is still listed after its due time plus a tolerance has not run. Give each test event its own hook name, because WordPress ignores a second one-off event with the same hook name within ten minutes of an existing one unless the arguments differ.

  • Use hook names that are unique to the test and due at least ten minutes apart.
  • Check that no action is attached before relying on it: the WP Crontrol list shows "None", and WP-CLI's event list can show an actions field.
  • Delete any test event that is still listed when the test ends.

Reading the list of scheduled events

To see what is scheduled and what is overdue, the WP Crontrol plugin lists every event with its schedule, callback and next due time, can run an event immediately, and warns when it detects cron problems or events that missed their schedule. Its listing on 11 October 2026 showed version 1.22.0 and requirements of WordPress 6.6 and PHP 7.4, so check the current page before installing. It notes that deleting a core event is pointless because core recreates it, and that pausing a hook affects every event that shares it. For hands-on work, WP-CLI offers wp cron event run with --due-now to execute whatever is due, which is useful on a staging copy to see whether a task completes when forced.

  • Run due events on staging first and read any error they raise.
  • An event that repeatedly reappears after deletion belongs to a plugin that reschedules it.

What the paid job proves, and what it does not cover

The scheduling job has a published test price of GBP 195 and is accepted when three harmless scheduled test events, added by your site holder under their own names, each run within an agreed tolerance of their due time and the event list shows nothing overdue after an agreed observation period. No post is created or published for the test. It does not repair a plugin's own task code, clear a backlog in a shop's order queue, move your host or promise the exact second. A monthly check for scheduled tasks can be added to a standing service later.

  • Send the post or task that ran late, the times, your host and any cache plugin, never logins.
  • The price is an untested proposal and payment follows the agreed checks.

Sources and limits

  • WordPress plugin handbook: Cron Checked 2026-10-11.
    • WP-Cron checks its list of scheduled tasks on every page load and runs what is due; it is only triggered on page load and so timing is not exact.
    • A system scheduler does not retry a missed time, whereas WP-Cron holds tasks and runs them at the next opportunity.
  • WordPress plugin handbook: hooking WP-Cron into the system task scheduler Checked 2026-10-11.
    • The documented route is a system scheduler that requests wp-cron.php, with define( 'DISABLE_WP_CRON', true ) added to wp-config.php; the page says WordPress will otherwise continue to run WP-Cron on each page load, which is no longer necessary and adds extra resource usage. Its examples request wp-cron.php with wget or PowerShell, and the page does not recommend one frequency.
  • WordPress developer handbook: wp-config.php Checked 2026-10-11.
    • DISABLE_WP_CRON set to true turns WordPress cron off; WP_CRON_LOCK_TIMEOUT limits how often cron runs; the page says an alternative cron (ALTERNATE_WP_CRON) is most commonly used if scheduled posts are not getting published as predicted, works by redirecting the visitor's browser, and carries a risk because it depends on a non-native WordPress service.
  • WP Crontrol plugin listing Checked 2026-10-11.
    • It lists scheduled events with their schedule, callback and next due time, can add new cron events, can run events immediately, and shows a warning if it detects cron problems or events that missed their schedule.
    • It alerts you to events that have no actions, and describes such an event as having no corresponding functionality that will be triggered when it runs.
    • On 11 October 2026 it showed version 1.22.0, requiring WordPress 6.6 and PHP 7.4.
  • WP-CLI: wp cron event run Checked 2026-10-11.
    • The --due-now option executes every hook whose time has come; --all executes every hook whether or not it is due; --network applies it across a multisite installation.
  • Paid Memberships Pro documentation: caching Checked 2026-10-11.
    • That vendor says sites that are heavily cached may not trigger WP Cron, which can cause issues with member expiration and other scheduled tasks.
  • WP-CLI: wp cron event schedule Checked 2026-10-11.
    • The command schedules a new cron event for a hook name, with an optional next-run time (a Unix timestamp or text that strtotime accepts, default now) and an optional recurrence (default none).
  • WP-CLI: wp cron event list Checked 2026-10-11.
    • The command lists scheduled cron events; by default it shows hook, next run and recurrence, and an actions field is optionally available.
  • WordPress developer reference: wp_schedule_single_event() Checked 2026-10-11.
    • It schedules an event to run only once, and scheduling an event within 10 minutes of an existing event with the same action hook is ignored unless the arguments differ.
  • WordPress source: wp-cron.php Checked 2026-10-11.
    • For each due event the source reschedules it if it recurs, removes the original entry from the schedule and then fires its hook, so a one-off event no longer appears in the event list once it has run.