Don’t Just “Fix” WP-Cron. Replace It. Here’s How.

Got a call from a client running a pretty busy WooCommerce store. Their inventory sync with a supplier’s API, which was supposed to run every 15 minutes, was completely out of whack. Sometimes it worked, sometimes it didn’t. To make matters worse, their daily sales reports weren’t being generated reliably. The whole thing was a mess, and it was costing them money in oversells and bad data. The culprit? A classic case of relying on a WordPress cron job for a business-critical task.

Let’s get one thing straight: WP-Cron is not a real cron. It’s not a daemon or a service that runs continuously on your server. It’s a fake cron system that piggybacks on website traffic. A scheduled task only has a *chance* to run when someone—a customer, a crawler, you—visits the site. If you have a high-traffic site, it might feel reliable. But for critical tasks, especially those scheduled during low-traffic hours? It’s a gamble. Total nightmare.

The Obvious Fix That Isn’t a Fix

My first thought? Just bypass the traffic dependency. I SSH’d into the server and set up a proper system cron job to hit the wp-cron.php file every five minutes. It’s the go-to solution you’ll find on a dozen forums. And yeah, it forced the WordPress cron job schedule to run like clockwork. But it felt… dirty. We were still pushing everything through the same old, fragile WP-Cron queue. We made the trigger reliable, but the underlying system was still the problem. It was a patch, not a proper fix.

The real issue is that when you lean on WP-Cron, your critical tasks are tied to the WordPress request lifecycle. If one task hangs, it can jam up the whole queue. As I was thinking through this, I remembered a post from a while back by Carl Alexander about his first open-source project, Chronos, which was born from a similar need for a better scheduling system. It reinforced the idea that for serious work, you have to get it out of the main application flow.

Decouple Your Tasks for True Reliability

The real solution is to decouple the task execution from WordPress itself. Stop using wp_schedule_event for anything that matters. Instead, build a simple PHP script that can be executed directly from the command line. This script handles one specific job and handles it well.

<?php
// file: /path/to/your/wp-content/cli/sync-inventory.php

// Bootstrap WordPress to get access to its functions
require_once( __DIR__ . '/../../wp-load.php' );

function do_inventory_sync() {
    // Your actual sync logic here.
    // Connect to the API, get the data, update products.
    $api_data = wp_remote_get('https://supplier-api.com/inventory');
    if ( is_wp_error( $api_data ) ) {
        error_log( 'Inventory sync failed: ' . $api_data->get_error_message() );
        return;
    }
    
    $inventory = json_decode( wp_remote_retrieve_body( $api_data ), true );

    // Process the inventory...
    // update_post_meta( $product_id, '_stock', $new_stock_level );

    error_log('Inventory sync completed successfully.');
}

// Run the function
do_inventory_sync();

exit(0);

Once you have that script, you set up a real server cron job to execute it directly. No more hitting a URL. You run it right from the shell.

*/15 * * * * /usr/bin/php /path/to/your/wp-content/cli/sync-inventory.php >/dev/null 2>&1

So, What’s the Point?

The takeaway is simple. WP-Cron is perfectly fine for non-essential maintenance tasks. Things like checking for theme updates or clearing out old transient data. But the moment a task involves money, data integrity, or any kind of business-critical function, you have to treat it like a professional developer and use the right tools.

• Reliability: Server cron jobs run on a schedule. Period. They don’t care if your site has zero visitors or a million.
• Isolation: The task runs in its own process. It isn’t fighting for resources with a visitor trying to load your homepage.
• Control: You have direct control over the execution environment and can handle logging and errors much more effectively. For heavy tasks, you could even run them via a more robust system like AWS Lambda.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

Stop treating WP-Cron like a reliable scheduler. It’s not. Use the right tool for the job and save yourself—and your clients—a massive headache.