WP‑Cron Overhead on Low‑Traffic WooCommerce Sites: Is Disabling Worth It?

Short answer

Yes, disabling WP‑Cron and moving execution to a real system cron is generally worthwhile on a low‑traffic WooCommerce store, but the CPU savings per page view are small and the real benefit is predictability, not raw performance. The trade‑off is a scheduling delay of up to your cron interval, which matters for time‑sensitive tasks like subscription renewals. Exact overhead numbers depend heavily on your plugin stack, so treat any figures below as estimates to verify on your own staging copy, not as guarantees.

What is likely true vs. what is confirmed

Confirmed behavior (well‑established WordPress/WooCommerce mechanics):

• When DISABLE_WP_CRON is not set, WordPress checks for due cron events on front‑end requests and spawns a non‑blocking loopback request to wp-cron.php when events are due.
• Setting define('DISABLE_WP_CRON', true); in wp-config.php stops that per‑request check/spawn; scheduled events then only run when wp-cron.php is invoked externally (system cron) or via WP‑CLI (wp cron event run --due-now).
• WordPress cron has no sub‑interval guarantee: a due event runs on the next trigger after its scheduled time. With a 5‑minute system cron, worst‑case added latency is just under 5 minutes.
• WooCommerce Subscriptions processes renewals through scheduled actions (Action Scheduler in current versions), so they are subject to the same trigger delay.

Likely, but you should measure it yourself: the per‑request CPU cost of the WP‑Cron check on a modest store is typically in the low‑millisecond range when no events are due, rising when events actually fire. On 10–20 page views per day, the absolute daily saving is trivial; the more common motivation is avoiding a slow first‑hit request when a backlog of due tasks fires on a real visitor. I can't give you a verified millisecond figure for your stack — it varies with plugin count, Action Scheduler queue size, and hosting CPU.

When disabling causes missed or delayed renewals

• Delays: any renewal scheduled between cron ticks waits for the next tick. With a 5‑minute interval, expect 0–5 minutes of added latency. For most stores this is harmless; for gateways or fraud hooks expecting immediate processing, test first.
• Misses: events are not normally lost — they stay in the queue until a trigger runs them. True misses happen when the system cron itself fails: wrong PHP path, wrong file permissions, wp-cron.php blocked by a firewall or security plugin, fatal PHP errors during the run, or a host that blocks loopback HTTP (use the CLI path or WP‑CLI instead).
• Overlap: if a task runs longer than the cron interval, concurrent runs can pile up. Prefer wp cron event run --due-now or a lock‑file wrapper to prevent overlap.

Does a 5‑minute system cron guarantee reliability?

No schedule alone guarantees execution — reliability comes from the cron actually running successfully. A 5‑minute interval is sufficient for WooCommerce's task granularity, but verify: check cron exit codes in syslog or cron mail, and confirm the cron option in wp_options (or the Action Scheduler tables) clears due events after each run. Residual due events after a run mean something failed.

How to measure the overhead yourself

1. On a staging copy, profile a typical product page with WP‑Cron enabled (Query Monitor, XHProf, or ab/wrk plus server CPU sampling).
2. Add define('DISABLE_WP_CRON', true); and a crontab entry such as:

   */5 * * * * cd /var/www/example.com && wp cron event run --due-now >/dev/null 2>&1

3. Re‑run the identical load test; the delta is your real per‑request saving.
4. Create a test subscription renewing ~10 minutes out, let the time pass, run the cron manually, and confirm the renewal fires. Repeat with 4‑ and 6‑minute intervals to observe the delay envelope.

One detail that changes the recommendation

Do you serve most pages from a full‑page cache (plugin, Nginx/Varnish, or Cloudflare)? If cached hits never bootstrap WordPress, WP‑Cron already isn't running on most requests — and worse, with WP‑Cron enabled it may never fire at all on a very low‑traffic cached site. In that scenario a system cron is not about CPU savings but about tasks running at all, which makes the recommendation stronger, not weaker. Assumed versions: WordPress 5.x/6.x and WooCommerce 7.x/8.x; older WooCommerce used direct WP‑Cron events instead of Action Scheduler, so verify which your install uses.