Replacing wp-cron.php with Real Cron on WordPress

On most WordPress and WooCommerce sites, hundreds of small background tasks keep things running smoothly: order emails, stock updates, subscription renewals, follow-up reminders, database cleanups and more. By default, all of these are driven by wp-cron.php, a pseudo-scheduler that only runs when someone visits your site. That design is convenient for cheap hosting, but it is not ideal when you care about reliable timing, heavy traffic, or money-making WooCommerce orders. In this guide, we will walk through why relying only on wp-cron.php is risky, what “real” server cron actually does, and how to switch your WordPress site to use proper cron jobs without breaking anything. We will focus on practical setups that work on shared hosting, VPS and dedicated servers, and we will highlight WooCommerce-specific pitfalls so your orders, emails and inventory stay in sync even during traffic spikes or quiet nights.

Why wp-cron.php Becomes a Problem for Real Sites

wp-cron.php is not a real scheduler. It is just a PHP file that WordPress tries to call on each page load to check whether any scheduled tasks are due. This brings several problems that show up quickly on production sites.

Low-traffic sites: missed or delayed jobs

On a brochure site with a few visits per day, wp-cron might never run at the exact time you scheduled something. If nobody visits your site at 03:00, a “run at 03:00” job may wait until 11:00 when the next visitor arrives.

• Abandoned cart emails are sent many hours late.
• Daily database cleanups run irregularly, if at all.
• Time-limited coupons or sales banners do not change on time.

For WooCommerce stores, such delays can directly hit revenue and support workload.

High-traffic sites: duplicate and overlapping runs

On a busy WooCommerce store with many concurrent visitors, the opposite problem appears: too many wp-cron calls. Multiple visitors may trigger wp-cron.php at nearly the same time. While WordPress tries to lock the process, in the real world you often see:

• Time-intensive jobs (like huge email batches) running multiple times.
• Extra CPU and I/O pressure because wp-cron starts on top of each page request.
• Slow checkout pages because PHP-FPM is busy processing background tasks.

This is exactly the kind of hidden load that later shows up as high TTFB, increased 5xx errors, and checkout slowness. If you want to dive deeper into these performance issues, our guide on fixing high TTFB on WordPress and PHP sites is a good companion read.

Why this matters so much for WooCommerce

WooCommerce relies heavily on scheduled tasks to maintain consistency:

• Order status transitions (on-hold to cancelled after X minutes, pending payments cleanups).
• Stock reservations and release of stock from unpaid orders.
• Subscription renewals and recurring payments (via WooCommerce Subscriptions or similar plugins).
• Follow-up emails, coupon expirations, membership access windows.

If wp-cron runs too late, not at all, or multiple times, you can end up with:

• Customers receiving duplicate or missing emails.
• Incorrect stock numbers or overselling during campaigns.
• Subscriptions not renewing on time, leading to support tickets.

That is why one of the first reliability upgrades we recommend for serious WooCommerce sites on our infrastructure is to disable wp-cron.php and move to real cron.

How WordPress Scheduling Works Behind the Scenes

Before changing anything, it helps to know what is happening under the hood.

WP-Cron events in the database

WordPress stores scheduled events in the wp_options table under a special option called cron. Each event has:

• a timestamp (when it should next run),
• a hook name (e.g. woocommerce_cancel_unpaid_orders),
• optional arguments, and
• a recurrence (single run or repeating interval).

When wp-cron.php runs, WordPress loads that data, finds due events, and fires the corresponding hooks, which plugins listen to.

What triggers wp-cron.php?

On each normal page load, WordPress checks if there are overdue events. If yes, it tries to call wp-cron.php asynchronously (using a loopback HTTP request). This means:

• Cron can start only when there is traffic.
• Cron runs via HTTP, not directly via PHP CLI on the server.
• Firewall or authentication settings sometimes block this internal HTTP call.

When we introduce real cron, we still rely on the same internal scheduling system (events, hooks, wp_options row). The only difference is how wp-cron.php is triggered: by the server’s scheduler instead of visitors.

Real Cron vs wp-cron.php: What You Gain

A real cron job is a native system scheduler entry (on Linux or via your hosting panel) that runs commands at fixed times, regardless of traffic. When you replace automatic wp-cron with a real cron job, you keep all of WordPress’ scheduling logic but improve how it is launched.

Predictable timing

With real cron, you control exactly when wp-cron.php runs. Examples:

• Every 5 minutes for order processing and email queues.
• Every minute during a big campaign if you have heavy queues.
• Once at 03:00 for nightly backups or maintenance tasks.

Tasks run even if nobody visits your site, which is critical for scheduled promotions or delayed workflows.

Lower overhead on page loads

Once you disable the automatic wp-cron trigger, every front-end or admin request becomes lighter:

• No more additional HTTP loopback requests to wp-cron.php.
• Less CPU spikes during busy hours.
• Fewer random slow requests caused by cron tasks starting mid-visit.

On WooCommerce stores, this helps keep checkout fast and stable, especially when combined with tuned PHP-FPM settings and database optimization. If you are planning for bigger traffic, our article on WooCommerce capacity planning for vCPU, RAM and IOPS is worth reviewing alongside cron changes.

Better reliability for money-critical workflows

Payment confirmation emails, invoice generation, subscription renewals and stock synchronizations should not depend on whether a random visitor happens to load a page. With real cron, these workflows become:

• Deterministic: they always run at the defined interval.
• Auditable: you can log or monitor cron runs from the system side.
• Easier to debug: because you can manually rerun the cron command from SSH.

Plays nicely with background job strategy

If you are already thinking about queues, workers and other background processes on your VPS, replacing wp-cron is a natural step. We discussed why background jobs matter and how to design them in our guide why background jobs matter so much on a VPS. WordPress and WooCommerce scheduling should be treated with the same seriousness.

Preparing Your Hosting or Server for Real Cron

The exact steps differ a bit depending on where your WordPress runs, but the principle is the same: disable auto wp-cron, then create a system cron entry that calls wp-cron.php at the interval you choose.

Shared hosting with cPanel or DirectAdmin

On most decent shared hosting plans (including those at dchost.com), you have a “Cron Jobs” or “Scheduled Tasks” section in the control panel. This lets you:

• Specify the execution interval (e.g. every 5 minutes).
• Run a PHP command pointing to your WordPress wp-cron.php.
• Optionally receive email if the cron job outputs errors.

If you would like a screenshot-level tutorial, we have a separate walkthrough on disabling wp-cron and using real cron jobs for WordPress on cPanel and VPS. In this article we will stay a bit more platform-neutral and focus on concepts and safe patterns.

VPS, dedicated or colocated servers

On a VPS or dedicated/colocation server, you have direct access to the system scheduler (crontab). This gives you more flexibility:

• Run cron via the PHP CLI binary you choose (matching your FPM version).
• Use crontab -e to edit schedules per-user, or system-wide.
• Combine WordPress cron runs with other maintenance and backup schedules.

If you are new to Linux cron, our guide on Linux crontab best practices for safe backups, reports and maintenance covers log handling, locking and other precautions that also apply to WordPress cron.

Step 1: Disable Automatic wp-cron.php

The first step is to stop WordPress from trying to trigger cron on every page load. This is done by adding one line to wp-config.php.

Editing wp-config.php

Open wp-config.php in your site’s root directory and add the following line above the line that says /* That's all, stop editing! */:

define('DISABLE_WP_CRON', true);

Save the file and upload it if you edited it locally. From this moment on:

• WordPress will no longer try to call wp-cron.php automatically on page loads.
• All scheduled events are still stored in the database as before.
• It becomes your job to run wp-cron.php via real cron.

What if you forget to add real cron?

If you set DISABLE_WP_CRON to true but do not add a system cron job, scheduled tasks will not run at all. New orders will still be accepted, but background tasks like cleaning pending orders or sending scheduled emails can stop. So always treat this change and the next step (creating real cron) as a single operation.

Step 2: Create a Real Cron Job for wp-cron.php

Now we will set up the actual cron job that will call wp-cron.php on a fixed schedule.

Core command pattern

The most robust pattern on Linux-based hosting is to run wp-cron.php through the PHP CLI:

/usr/bin/php -q /home/USERNAME/public_html/wp-cron.php >/dev/null 2>&1

Explanation:

• /usr/bin/php – path to PHP CLI (check with which php on a VPS).
• -q – quiet mode (no HTTP headers).
• /home/USERNAME/public_html/wp-cron.php – full filesystem path to your site’s wp-cron.php.
• >/dev/null 2>&1 – discard output to avoid filling your inbox or logs unless there is a problem you are actively debugging.

cPanel: adding the cron job

1. Log in to cPanel and open Cron Jobs.
2. In the “Add New Cron Job” section, pick a common setting like “Every 5 minutes” or choose custom values:

*/5 * * * * /usr/bin/php -q /home/USERNAME/public_html/wp-cron.php >/dev/null 2>&1

3. Replace USERNAME and the path to match your hosting account.
4. Save. The job will now run every 5 minutes.

DirectAdmin or similar panels

Other panels (DirectAdmin, Plesk, etc.) have a similar “Cron” or “Scheduled Tasks” section. The core command is the same; only the interface differs. Paste the /usr/bin/php ... wp-cron.php command and set the interval to 5 minutes as a starting point.

Plain Linux with crontab

On a VPS or dedicated server without a panel, you can add cron jobs directly from the shell:

1. SSH into your server.
2. Run crontab -e as the user that owns your WordPress files (often the same user that runs PHP-FPM for that site).
3. Add a line like this:

*/5 * * * * /usr/bin/php -q /var/www/example.com/public_html/wp-cron.php >/dev/null 2>&1

4. Save and exit. Cron will pick up the new schedule automatically.

If you are designing a more advanced VPS stack, our guide on background jobs and queue management on a VPS also gives you ideas on structuring systemd units and supervisors around cron-driven workloads.

Choosing the right frequency

How often should you run wp-cron.php? It depends on your site’s profile:

• Small blogs or corporate sites: every 10–15 minutes is usually enough.
• Standard WooCommerce store: every 5 minutes is a good balance.
• High-order-volume stores or heavy email automation: every 1–2 minutes during peak hours can make sense.

You can also run multiple cron entries with different frequencies if needed (e.g. a fast one for queue processing and a daily one for heavy reports), but in most WordPress setups, a single 5-minute cron is sufficient.

Step 3: Testing Your New Cron Setup

Before you forget about it, you should verify that the new cron job is actually running and that WordPress events are being processed.

Manual trigger from the command line

If you have SSH access, run the command manually once:

/usr/bin/php -q /var/www/example.com/public_html/wp-cron.php

If the command finishes quickly and does not output errors, WordPress cron is executing. If you see PHP errors, fix these first before relying on cron.

Using WP Crontrol to inspect events

A popular debugging approach is to temporarily install the WP Crontrol plugin:

• Go to Tools → Cron Events.
• Check the “Next run” times of scheduled hooks.
• Wait a few minutes after your new cron job has run.
• Refresh and confirm that “Next run” timestamps move forward as expected.

This is especially helpful for confirming that WooCommerce-specific events (like woocommerce_cleanup_sessions or woocommerce_cancel_unpaid_orders) are running on schedule.

Watching logs and notifications

During the first days, you might want cron to send output to an email address rather than /dev/null. Simply remove the >/dev/null 2>&1 part and set a valid email in your panel. Once you are confident everything works, you can switch back to discarding normal output to avoid spammy notifications.

Multiple WordPress Sites on One Server

If you host many WordPress sites on the same server (agencies, freelancers, or multi-brand companies), you have two main strategies.

One cron job per site

The simplest and most common approach is:

• Create a separate cron entry for each WordPress install.
• Point each entry to that site’s own wp-cron.php.
• Set the frequency according to each site’s needs (e.g. busy WooCommerce stores every 2–5 minutes, simple blogs every 15 minutes).

This keeps sites isolated. A spike in scheduled tasks on one site does not delay cron for others.

A central runner using WP-CLI (advanced)

If you are comfortable with WP-CLI, you can centralize cron execution:

*/5 * * * * /usr/local/bin/wp cron event run --due-now --path=/var/www/site1 && 
             /usr/local/bin/wp cron event run --due-now --path=/var/www/site2 && 
             /usr/local/bin/wp cron event run --due-now --path=/var/www/site3

Here, WP-CLI directly runs due events via cron event run --due-now, bypassing wp-cron.php. This gives you finer control and clearer exit statuses, but it is an advanced pattern and requires WP-CLI installed system-wide.

For agencies hosting dozens of WordPress sites on one stack, combining real cron with good isolation and monitoring is key. Our article on hosting architecture for agencies managing 20+ WordPress sites on one infrastructure dives deeper into this topic.

WooCommerce-Specific Scheduling Considerations

Once real cron is in place, you can tune it to keep WooCommerce order flows smooth.

Order status timeouts and cancellations

WooCommerce uses scheduled events to cancel unpaid orders after a configurable time. With unreliable wp-cron, those cancellations can be delayed for hours or happen in a messy burst. Real cron running every few minutes gives you:

• Timely cancellation of unpaid orders, freeing reserved stock.
• Predictable email sequences around these changes.
• Cleaner reporting because old “pending” orders are not hanging around indefinitely.

Subscriptions and memberships

Plugins like WooCommerce Subscriptions and various membership tools rely heavily on cron to:

• Generate renewal orders.
• Charge stored payment methods via gateways.
• Activate or deactivate access based on start/end dates.

Real cron significantly reduces support tickets like “my subscription did not renew” or “I paid but did not get access”, because the scheduler is no longer tied to random visits.

High-traffic campaigns and flash sales

During big campaigns or flash sales, WooCommerce stores can experience:

• Sudden spikes in orders and session data.
• Bigger background workloads (events, emails, stock updates).

Combining a solid cron strategy with database tuning helps keep checkout responsive. For larger catalogs and heavier stores, have a look at our guide on MySQL indexing and query optimization for WooCommerce; it pairs very well with real cron for keeping order processing smooth.

Performance, Locking and Safety Tips

Replacing wp-cron is not just about adding one line to crontab. A few extra details make the setup more robust and easier to operate.

Use the correct PHP binary

On some servers, /usr/bin/php might be a different version than the one used by your web server (PHP-FPM). Ideally, you want the CLI version to match the FPM version. Check with:

/usr/bin/php -v

If the version is different, consult your hosting documentation or support to find the right CLI path (for example, /opt/php82/bin/php).

Avoid overlapping cron runs

If your scheduled tasks occasionally take longer than the cron interval (e.g. a large newsletter send), two runs can overlap. Some plugins handle this with internal locking, but to be safe you can introduce a simple lockfile mechanism around your cron command on a VPS:

*/5 * * * * flock -n /tmp/wp-cron.lock /usr/bin/php -q /var/www/example.com/public_html/wp-cron.php >/dev/null 2>&1

flock -n /tmp/wp-cron.lock ensures that if one cron run is still executing, the next scheduled one will exit immediately instead of piling up.

Keep an eye on resource usage

On busy WooCommerce sites, cron can generate noticeable CPU, RAM and I/O load during heavy processing (e.g. bulk updates, big imports, marketing automation). Monitoring tools like htop, Netdata or a full Prometheus/Grafana stack help you spot patterns. Our starter guide to VPS monitoring and alerts with Prometheus, Grafana and Uptime Kuma shows how to build a calm, informative monitoring setup around cron and other workloads.

Do not forget backups

Changing scheduling often goes hand-in-hand with improving backup routines. Real cron gives you a perfect place to hook nightly database and file backups. On managed panels this is often automated, but on VPS or dedicated servers, you can combine WordPress cron with database dumps and off-site backups triggered from the same crontab. If you need a structured approach, our 3-2-1 backup strategy and automation guides on the blog will help you design a safe plan.

When wp-cron.php Is Still “Good Enough”

Not every site must immediately migrate to real cron. wp-cron.php can be acceptable if:

• Your site has very low complexity (simple blog or one-page site).
• You have no WooCommerce or subscription/membership logic.
• Small delays in scheduled tasks do not matter.

Even then, keep in mind that most shared hosting panels make real cron very easy to configure. So if you are already editing wp-config.php and you have access to Cron Jobs in your panel, it is usually worth spending an extra minute to set up a proper schedule. Future you will be happy when you add WooCommerce, forms, or marketing plugins later.

Summary and Next Steps

Replacing WordPress’ default wp-cron mechanism with a real server cron job is one of those small infrastructure changes that dramatically improves reliability without adding ongoing complexity. You keep WordPress’ familiar scheduling model, but you move the trigger from “only when someone visits” to “exactly when the server decides”. For WooCommerce stores, this means more predictable order processing, on-time subscription renewals, fewer double emails, and more consistent stock levels. For busy blogs and content sites, it eliminates random slow requests and makes background cleanups easier to monitor.

At dchost.com we strongly encourage customers running serious WordPress and WooCommerce workloads to make this switch early in the project, alongside other basics like correct PHP-FPM tuning, database optimization and a sound backup strategy. If you are using our shared hosting, VPS, dedicated or colocation services and want help determining the right cron interval or command for your setup, our support team can review your environment and suggest a safe configuration. Once real cron is in place and tested, you can move on to the next optimizations—object caching, database indexing, and scaling plans—knowing that your scheduled tasks are finally running on a solid foundation.