Disable default WP cron job for performance (and do it the right way)

TL;DR: WordPress’ built‑in cron (WP‑Cron) runs on page loads. On busy sites it can add overhead; on quiet sites it can miss schedules. The fix is simple: disable the default trigger in wp-config.php and run wp-cron.php from a real scheduler (Linux cron, Windows Task Scheduler, or a third‑party ping) every 5–10 minutes. Verify with WP‑CLI and keep an eye on heavy jobs like WooCommerce’s Action Scheduler.

Why WP‑Cron hurts performance

WP‑Cron is a pseudo cron. It checks for due tasks on each page request and then tries to run them. That creates two common problems:

• High traffic: each request can spawn cron work, competing with real visitors for PHP workers and CPU. You’ll see extra concurrent requests to /wp-cron.php during spikes.
• Low traffic: jobs only run when someone visits, so “publish at 08:00” becomes “publish whenever the next person arrives.”

Typical symptoms: random slow spikes, scheduled posts missing their time, WooCommerce emails delayed, backups overlapping with peak traffic, or admin notices like “there was a problem spawning a scheduled task.”

When you should disable the default WP‑Cron trigger

You almost always benefit on production, especially if:

• You run WooCommerce or anything using Action Scheduler (marketing automations, imports/exports, webhooks). See WooCommerce’s Scheduled Actions docs.
• You have backups, feeds, or syncs scheduled.
• You use full‑page caching/CDN and want deterministic timings.
• You’ve seen missed schedule or spawn errors in the logs.

Local dev and tiny brochure sites can leave it as‑is, but standardising on a real cron keeps behaviour consistent across environments.

What “real cron” is (and how it differs from WP‑Cron)

A real cron is the operating system’s time‑based scheduler. On Linux and other UNIX‑like systems it’s provided by the cron daemon (crond). Jobs live in a crontab and run at the exact times you define—independent of web traffic, browsers, or PHP workers.

A minimal crontab entry looks like this:

# ┌ minute (0–59)
# │ ┌ hour (0–23)
# │ │ ┌ day of month (1–31)
# │ │ │ ┌ month (1–12)
# │ │ │ │ ┌ day of week (0–7, Sun=0 or 7)
# │ │ │ │ │
# * * * * *  command to run

Windows offers a similar system via Task Scheduler, where you define a trigger (e.g., every 5 minutes) and an action (e.g., call wp-cron.php or run wp.exe cron event run --due-now).

Real cron vs WP‑Cron at a glance

• Trigger source: Real cron is driven by the OS clock; WP‑Cron is triggered on page load (an HTTP request).
• Timing accuracy: Real cron runs to the minute you set; WP‑Cron runs “whenever someone visits.” Quiet sites miss exact times; busy sites may spawn competing runs.
• Execution environment: Real cron usually runs CLI commands (PHP CLI, shell scripts, binaries) outside the web server and CDN. WP‑Cron executes inside a web request to /wp-cron.php, inheriting web timeouts, WAF/CDN rules, and PHP‑FPM worker limits.
• Resource isolation: Real cron jobs are separate processes and can be constrained/tuned (e.g., nice, ionice, systemd units, concurrency). WP‑Cron competes with front‑end PHP workers, causing spikes during traffic peaks.
• Reliability/observability: Real cron integrates with system logging and exit codes; failures are easier to track and alert on. WP‑Cron failures can be silent until the next visitor or show “spawn” warnings in admin.
• Security and access: Real cron requires server access (or a trusted external pinger). WP‑Cron can be blocked by auth, firewalls, or cache layers.
• Multisite behaviour: One scheduler can cover a whole network with wp cron event run --due-now from the network root. With WP‑Cron, timing depends on visits across subsites.

Bottom line: WP‑Cron is a convenient fallback but not a scheduler. Production sites should disable its page‑load trigger and use a real scheduler to fire jobs predictably.

Step 1 — Disable WP‑Cron on page load

Edit wp-config.php and add this above the line that says “That’s all, stop editing! Happy publishing.”

// Disable the default WP‑Cron trigger (runs on page load)
define('DISABLE_WP_CRON', true);

This does not disable WordPress’ scheduling system itself; it only stops the automatic trigger on page views. You’ll provide your own trigger in the next step.

Pro tip: If you previously enabled the fallback ALTERNATE_WP_CRON, remove it now to avoid odd redirects and ?doing_wp_cron URLs.

Step 2 — Replace it with a real scheduler

Pick one of these options. The goal is simply to hit wp-cron.php on an interval.

A) Linux server (crontab)

Run every 5 minutes (safe default for most shops and blogs):

*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Prefer curl?

*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Further reading: Kinsta’s walkthrough on disabling WP‑Cron and scheduling a system cron.

If you host multiple sites on one box, stagger them (e.g., */5 plus different minute offsets) to avoid bursting all jobs at once.

B) WP‑CLI (no HTTP request)

If you have SSH access, you can execute due events via WP‑CLI:

*/5 * * * * /usr/bin/wp --path=/var/www/example.com/public_html cron event run --due-now >/dev/null 2>&1

This runs jobs directly in PHP/CLI, bypassing web server constraints and some cache/CDN quirks. See WP‑CLI: wp cron event list, wp cron event run, and wp cron test.

C) Windows Task Scheduler

Create a Basic Task that runs every 5–10 minutes and executes:

powershell "Invoke-WebRequest https://example.com/wp-cron.php"

Reference: WordPress Plugin Handbook: Hooking WP‑Cron into the system task scheduler.

D) Third‑party ping service

If your host doesn’t expose cron, use a reliable external pinger (EasyCron, cron-job.org, etc.) to GET https://example.com/wp-cron.php?doing_wp_cron on your desired schedule.

Verifying it works (and monitoring)

Use WP‑CLI for instant feedback:

# List scheduled events
wp cron event list

# Manually run anything that is due now
wp cron event run --due-now

# Test the spawn system (helpful before you switch)
wp cron test

Docs: WP‑CLI — event list, event run, cron test.

What to look for:

• No growing backlog of overdue jobs.
• Heavy hooks (backups, imports, wc_*) finish within your interval.
• Scheduled posts/emails go out on time.

Gotchas and production notes

• Caching/CDN: Some page caches or security layers can block wp-cron.php. Whitelist it and bypass full‑page cache for that path. If your CDN uses “Under Attack” modes, scheduled jobs may stall.
• Basic/Auth or maintenance mode: If the site requires auth, wp-cron.php will need credentials or a CLI approach.
• ?doing_wp_cron parameter: Totally fine to keep; it ensures the cron request isn’t cached and helps WordPress track a run. More info: Why is ?doing_wp_cron being appended to my URLs?.
• Multisite: One network‑level trigger is typically enough; subsites’ jobs will run when WordPress loads. If you rely on domain‑mapped subsites with separate traffic patterns, consider WP‑CLI’s --due-now from the network root.
• Intervals: 5 minutes is a practical starting point. Low‑activity sites can push to 10–15 minutes; busy shops sometimes go to 1–2 minutes for time‑sensitive flows.
• Stagger the heavy stuff: If imports, backups, and marketing automations all line up at 00/05/10, move some to 02/07/12 to avoid spikes.
• Plugins that assume page‑load cron: Rare today, but if a plugin expects the page‑load trigger, keep an eye on it after switching.

Rollback

Need to revert quickly? Remove the DISABLE_WP_CRON line and delete your server task. WordPress will go back to page‑load triggering immediately.

FAQ

Will disabling WP‑Cron break scheduled posts?
No—provided you replace the trigger with a real scheduler. Scheduled posts (and everything else) keep working; they just run on your exact interval.

What frequency should I choose?
Start with every 5 minutes. If jobs routinely finish in seconds and you don’t need minute‑level precision, try 10–15 minutes. If you run a busy WooCommerce store with time‑sensitive automations, 1–2 minutes can be justified.

How do I see what’s actually scheduled?
wp cron event list is the fastest way. For a GUI, the WP Crontrol plugin is solid on staging. On production, prefer WP‑CLI and logs.

Why do I still see ?doing_wp_cron in URLs?
You likely had ALTERNATE_WP_CRON enabled at some point; remove it. Some tools append it intentionally on cron pings—it’s harmless.

Next steps / Need a hand?

We’ve implemented this on high‑traffic blogs, WooCommerce shops, and content platforms. If you’d like us to audit and harden your WordPress performance—from cron to caching, PHP workers, and database autoloads—get in touch.
We’ve implemented this on high‑traffic blogs, WooCommerce shops, and content platforms. If you’d like us to audit and harden your WordPress performance—from cron to caching, PHP workers, and database autoloads—get in touch.

Related reading

• If you’re hunting down mystery slowdowns, check our article on whether deactivated plugins slow down your site.
• Image handling can also balloon CPU/IO. See our guide on disabling unnecessary WordPress image sizes and choosing the sizes you actually need.