WordPress pseudo-cron—most people just call it WP-Cron—isn’t a real system cron job. It’s a conditional execution loop that only fires when an HTTP request hits your site. Every time someone loads a page, WordPress checks a queue of scheduled events, compares their timestamps to the current time, and runs any hooks that are overdue. No visitor, no request, no cron run. That’s the fundamental fragility. It breaks the moment a host disables real cron or blocks loopback connections without a heads-up. You find out through the symptoms: scheduled posts that never go live, backup plugins that skip cycles without a peep, stale object caches, missed transient expiration. For a small-to-mid publishing team, this isn’t a performance footnote. It’s a content operations failure. The editorial calendar grinds to a halt, and nobody gets an alert.
You need to understand a few adjacent pieces: the wp-cron.php bootstrap file, the spawn_cron() function inside wp-includes/cron.php, the ALTERNATE_WP_CRON constant, and the HTTP transport layer WordPress uses to self-request. When a host disables real cron, they usually neuter the internal loopback mechanism—often by blocking HTTP requests from the server to itself—or they yank the default DISABLE_WP_CRON constant and then fail to provide a system-level replacement. The result is a queue that grows silently until you notice editorial workflows breaking. This article maps the exact failure modes, shows you how to detect them before your team reports missing scheduled posts, and gives you a durable fix that doesn’t depend on host goodwill.
How WP-Cron Actually Fires (and Why It Fails Without Warning)
WordPress doesn’t use a persistent background daemon. Instead, on every page load, the function wp_cron() checks if any scheduled events are past due. If yes, it tries to spawn an HTTP request to /wp-cron.php with a non-blocking transport. The request carries a doing_wp_cron parameter and a transient-based locking mechanism to prevent overlapping runs. Here’s the critical detail: the spawn uses wp_remote_post() with a timeout of 0.01 seconds and blocking set to false. WordPress fires the request and immediately continues rendering the page, expecting the server to handle the cron request asynchronously.
Hosts that disable real cron often break this in two ways. First, they may set DISABLE_WP_CRON to true in a must-use plugin or via server-level configuration, which prevents the spawn from ever occurring. Second, they may block loopback HTTP requests at the firewall or web server level. When loopback is blocked, wp_remote_post() returns a WP_Error object, and the cron event never executes. The queue grows, and WordPress doesn’t surface a dashboard warning. You only notice when scheduled posts miss their time or when a plugin like WP Crontrol shows a ballooning list of overdue hooks.
How to Confirm the Failure Without Guessing
Don’t rely on plugin status pages alone. Start with a direct HTTP request from the server to itself. SSH into the server and run:
curl -I https://yourdomain.com/wp-cron.php?doing_wp_cronIf you get a 403, 500, or connection refused, the host is blocking loopback requests. Next, check if DISABLE_WP_CRON is set. Add this to a temporary mu-plugin or your theme’s functions.php:
add_action('init', function() {
if (defined('DISABLE_WP_CRON') && DISABLE_WP_CRON) {
wp_die('WP-Cron is disabled via constant.');
}
});If the constant is defined, you’ll see the message on any frontend request. If loopback is blocked, you can test by triggering a manual cron spawn and inspecting the HTTP response. Use WP-CLI if available: wp cron test will attempt a spawn and report errors. Without WP-CLI, install the WP Crontrol plugin and check the “Next Run” column for overdue events. Overdue events with no recent execution confirm the queue is stalled.
The Real Fix: Replace WP-Cron with a System Cron That Doesn’t Depend on Host Cooperation
The durable solution is to disable WordPress’s internal cron spawning entirely and invoke wp-cron.php via a genuine system cron job. This removes the dependency on loopback HTTP and ensures execution even when no visitors hit the site. The trade-off: you need access to the server’s crontab or a compatible external cron service. For small-to-mid publishing teams on managed hosting that blocks crontab, you can use a cron service that pings a custom endpoint.
Step one: disable WP-Cron’s self-spawning. Add this to wp-config.php:
define('DISABLE_WP_CRON', true);This stops WordPress from attempting the loopback request on every page load. It doesn’t disable the cron system itself; it only prevents the automatic spawn. The event queue still populates, and plugins can still schedule hooks.
Step two: create a system cron job that calls wp-cron.php directly. The command must execute as the web server user to avoid permission issues. On a typical cPanel or custom LAMP stack, the crontab entry looks like:
*/5 * * * * /usr/bin/php /home/username/public_html/wp-cron.php > /dev/null 2>&1If your host restricts PHP CLI execution, use wget or curl to hit the URL:
*/5 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1This approach still uses an HTTP request, but it originates from the server itself, bypassing most loopback blocks. If the host blocks even local HTTP requests, you need an external cron service. Services like EasyCron or Cron-job.org can ping your wp-cron.php URL on a schedule. Set the interval to 5 minutes or less, depending on your publishing cadence. For a newsroom that publishes hourly, a 1-minute interval is reasonable. For a weekly magazine, 10 minutes suffices.
Handling Hosts That Block All External Cron Pings
Some managed WordPress hosts aggressively block any request to wp-cron.php that doesn’t originate from their internal infrastructure. In this case, you need to create a custom endpoint that bypasses their rules. Register a custom REST API route that manually triggers the cron spawner:
add_action('rest_api_init', function () {
register_rest_route('jooom-cron/v1', '/trigger', array(
'methods' => 'GET',
'callback' => 'jooom_manual_cron_trigger',
'permission_callback' => '__return_true',
));
});
function jooom_manual_cron_trigger() {
spawn_cron();
return new WP_REST_Response('Cron triggered', 200);
}Then point your external cron service to https://yourdomain.com/wp-json/jooom-cron/v1/trigger. This bypasses the wp-cron.php file entirely and calls the spawner directly. Add a shared secret as a query parameter and validate it in the callback to prevent abuse. This pattern has kept editorial schedules intact on hosts that silently killed cron without notice.
Detecting Missed Schedules Before Your Team Does
Relying on editors to notice that a scheduled post didn’t go live is a reactive failure mode. You need a monitor that checks cron health independently. The simplest method: log every cron run to a custom database table or file, then use a separate system to check that the log is recent. If the last log entry is older than your cron interval plus a grace period, trigger an alert.
Add this to a must-use plugin:
add_action('init', function() {
if (isset($_GET['doing_wp_cron'])) {
update_option('jooom_last_cron_run', time());
}
});Then, from a monitoring server or a cron service, request a custom endpoint that checks the option value. If the timestamp is older than, say, 10 minutes, send an email to the editorial team or post to a Slack channel. This isn’t a theoretical safeguard; it catches the exact scenario where a host disables cron silently during a platform update.
If you’ve already encountered the “Nothing Found” error on a new site, the root cause is often a related misconfiguration in rewrite rules or permalink structures. See What to Fix First When a New WordPress Site Says Nothing Found for the debugging sequence that precedes cron troubleshooting in a fresh install.
Why the Queue Backlog Corrupts Editorial Workflows
When WP-Cron stalls, the event queue doesn’t simply pause; it accumulates. Hooks scheduled by plugins—backup rotations, cache purges, transient deletions—pile up. When execution finally resumes, the server attempts to process all overdue events in a single request. This can cause timeouts, memory exhaustion, and partial execution. A scheduled post might publish, but its associated cache purge hook fails, leaving the post invisible to readers. The failure is partial and silent, making it harder to diagnose than a complete outage.
For publishing teams, the most dangerous consequence is the missed schedule status. WordPress sets a post to “missed schedule” when wp_cron fails to fire the publish_future_post hook within a window after the scheduled time. Once a post enters this state, it will not publish automatically even if cron later resumes. You must manually change the status back to “future” or “publish.” This is a known core behavior, not a bug, but it punishes teams that rely on scheduled content without manual oversight.
Clearing the Backlog and Resetting Missed Schedules
After fixing the underlying cron execution, you need to clear the backlog and reset any missed schedule posts. Use WP-CLI:
wp cron event run --due-now
wp post list --post_status=missed-schedule --format=ids | xargs -n1 wp post update --post_status=futureIf you lack WP-CLI, install the Advanced Cron Manager plugin, which provides a UI to run pending events and a bulk action to reset missed schedule posts. Don’t rely on the plugin’s internal cron runner as a permanent fix; it still depends on site traffic. Use it only for cleanup, then implement the system cron solution described above.
Preventing Recurrence: A Cron Architecture That Survives Host Changes
Hosting companies change internal configurations without notice. A cron setup that works today can break tomorrow when they update firewall rules or migrate your site to a different server cluster. The only durable architecture is one that doesn’t depend on the host’s internal HTTP routing at all. If you have SSH access, use the PHP CLI method. If you don’t, use an external cron service with a custom REST endpoint that includes authentication. This decouples your editorial schedule from the host’s network topology.
For teams on managed hosting that prohibits both crontab and external pings, you have one remaining option: a real-time monitoring plugin that triggers cron via an internal server-side timer. These plugins use a combination of transients and shutdown hooks to simulate a persistent scheduler, but they’re fragile and can conflict with object caching. They’re a last resort, not a recommendation. The correct path is to move to a host that provides crontab access or to use an external cron service with a properly secured endpoint.
FAQ
Why do scheduled posts show as “Missed Schedule” even after cron is working again?
WordPress marks a scheduled post as “missed schedule” when the publish_future_post hook fails to fire within a certain window after the scheduled time. Once marked, the post will not automatically publish even if cron resumes. You must manually change the post status back to “future” or “publish.” This is a deliberate design choice to prevent accidental publication of content that may no longer be relevant after a delay.
Can I use a server-side cron job without disabling WP-Cron in wp-config.php?
You can, but you shouldn’t. If you leave DISABLE_WP_CRON undefined, WordPress will still attempt to spawn cron on every page load, creating unnecessary HTTP requests and potential race conditions with your system cron. Always define DISABLE_WP_CRON as true when using a real cron job. The constant only disables the automatic spawn; it doesn’t affect the cron system’s ability to process events when wp-cron.php is called directly.
How can I tell if my host disabled cron without notifying me?
Check the “Cron Schedules” or “Cron Events” panel in a plugin like WP Crontrol. Look for events with a “Next Run” timestamp in the past. If you see many overdue events and the site has consistent traffic, the internal cron spawner is likely blocked. Confirm by manually requesting /wp-cron.php?doing_wp_cron in your browser or via curl. A 403, 500, or connection error indicates a block. Also check your wp-config.php and any must-use plugins for the DISABLE_WP_CRON constant.
