WordPress Scheduled Posts Late? Check WP-Cron First

Imagine opening a quiet WordPress site and finding that a post scheduled earlier is still waiting. Publishing it by hand might solve today's problem. It leaves the next scheduled post depending on the same setup you haven't checked.

Start by checking the due event and the route that triggers WP-Cron. Low traffic can delay the normal trigger, but a failing task needs a different fix. If you replace the trigger with a host or system scheduler, verify the replacement before disabling the visitor-triggered route.

This is a hypothetical troubleshooting scenario. The commands below are illustrative, not results from a tested customer site.

A scheduled time isn't a continuously running clock

WordPress's Cron handbook explains that WP-Cron checks scheduled tasks when page requests trigger it; it doesn't run continuously like a system scheduler. Publishing scheduled posts is one of its jobs. A task can therefore become due while a quiet site has no request to start the check.

That makes a useful first distinction: the post's intended publication time tells you when it should become eligible; it doesn't prove a worker started at that moment. Before changing anything, record the post's status, intended time, the site's configured timezone and the time you observed the delay.

Then establish what currently starts cron. The site may use the normal WordPress route, an existing host scheduler, a plugin-managed arrangement or a deliberately configured external request. Don't add a second mechanism simply because the first one is invisible from the dashboard.

Keep the event, trigger and result separate

For the hypothetical late post, collect a small evidence trail. This helps you avoid treating a successful HTTP request as proof that WordPress published the right content.

If you have supported WP-CLI access, use the event-list command from the correct installation. Its documented fields include the hook, GMT next-run time, relative time and recurrence:

# Replace this path with the intended WordPress installation.
wp --path=/srv/www/example-site cron event list \
  --fields=hook,next_run_gmt,next_run_relative,recurrence

Compare GMT timestamps with a matching reference rather than reading them as your local wall clock. For multisite, identify the specific site before running diagnostics. If the event isn't present, investigate how the post or plugin scheduled it; more frequent triggers cannot execute work that was never registered.

On managed hosting without command access, ask the host for the equivalent event and trigger information. Send the affected post URL or ID, intended time with timezone, observed status and recent relevant changes. That is more actionable than asking for “cron to be fixed.”

Test the route you actually use

WP-CLI's cron test checks configuration constants and attempts an HTTP spawn. It is an active diagnostic that can trigger due work, so use a controlled site or an approved production window, especially if plugins send messages or call external services.

# Active diagnostic: can start due WordPress work.
wp --path=/srv/www/example-site cron test

A DISABLE_WP_CRON warning may describe an intentional external-scheduler setup. Verify that setup instead of removing the setting automatically. Similarly, a successful spawn test narrows the investigation; it doesn't verify each plugin's task or the scheduled post's final state.

If the HTTP path fails, inspect the specific response and the corresponding host logs. Check whether authentication, routing, a redirect or a security rule affects that request. Work with the host on the required route. Don't turn off site protection globally to make a diagnostic green.

If the trigger reaches WordPress but the work still fails, inspect the relevant PHP or application error around that attempt. WordPress's debugging handbook describes logging and display controls. Prefer existing protected logs or a test environment; don't expose errors or sensitive debug files publicly.

Also avoid changing the plugin load just to make a command succeed. A test that skips the plugin responsible for the callback may no longer represent the job you're trying to diagnose.

Replace the trigger only when that is the missing piece

For a site that needs checks independent of visits, WordPress documents calling wp-cron.php from a system task scheduler. On managed hosting, first confirm the supported method, interval, credentials and logging with the host. A cPanel-style interface is not evidence that every cron or shell feature is available on your plan.

On a self-managed Linux server, the following is an illustrative crontab entry for an HTTP trigger. It is not a command to paste into a shell and is not a universal interval recommendation. Replace the example domain, verify the curl executable path, and arrange for the scheduler's output and failures to be recorded.

# Example crontab entry: attempt a trigger every five minutes.
*/5 * * * * /usr/bin/curl --fail --silent --show-error --max-time 60 https://example.com/wp-cron.php

Choose the interval from the task's acceptable delay and observed runtime. A periodic trigger isn't an exact-to-the-second publication guarantee, and an HTTP timeout doesn't by itself tell you whether a callback continued. Check the application's result before manually retrying work with external effects.

Once the replacement has been verified, the WordPress handbook describes this setting in wp-config.php to stop the normal page-load spawning route:

define( 'DISABLE_WP_CRON', true );

Update an existing definition rather than adding a contradictory duplicate. Keep the configuration backup and the reversal steps. This setting does not install a replacement scheduler; setting it first and leaving the replacement untested can remove the route the site was relying on.

Prove the next scheduled post works

Return to the quiet-site scenario. The useful finish is a controlled scheduled post completing through the route you've chosen, with evidence from both the scheduler and WordPress. One manual publish or one successful diagnostic isn't that finish.

• Use a test site with outbound messages, payment calls and other live integrations disabled or safely configured.
• Schedule a harmless test post and record its intended time and timezone.
• Observe the configured scheduler without relying on an extra manual page visit to rescue the test.
• Check the actual publication status, relevant logs and the public result.
• Observe more than one trigger interval, including a quiet period, and investigate delayed or failing work rather than repeatedly forcing it.

For other tasks, verify their own outcomes too. WP-CLI's event-run command can run selected hooks or all due work. That is an execution tool, not a passive status check: review side effects and uncertain previous attempts before using it on production.

What to check when choosing hosting

Nest is Krova's managed hosting for WordPress and everyday websites, with a control panel, email, SSL and backups. For a site with time-sensitive tasks, ask which scheduler method is supported and how failed triggers are surfaced. This article does not claim a specific Nest cron interval, WP-CLI entitlement or publication-time guarantee.

If you're moving the site, carry that scheduler inventory into the WordPress migration checklist. Confirm that the intended environment owns the scheduled work before reopening integrations.

A Cube provides a Linux microVM with root access when you want to operate the server yourself. That gives you control over system scheduling, along with responsibility for WordPress maintenance, credentials and monitoring. Choose that responsibility deliberately.

Creation context: AI-assisted guidance based on the linked primary documentation, checked on 5 November 2026. No commands were run against a WordPress site, and no personal testing by the bylined author is claimed.