WordPress Cron: Hosting-Side Setup

WP-Cron isn’t a real cron job. It’s a page-load trigger: every time a visitor hits your site, WordPress checks whether any scheduled task (a post publish, a backup, a plugin’s scheduled sync) is overdue and, if so, fires it inline before finishing the page request. On a low-traffic site that’s mostly harmless. On a busier site, or one with several plugins scheduling frequent events, it means random visitors are the ones eating the CPU cost of your scheduled tasks — and if nobody visits for a few hours, scheduled posts and backups just don’t run on time.

The fix is to disable WP-Cron’s page-load trigger and replace it with a real, fixed-interval cron job at the hosting level. Every major host now supports this, but the exact setup screen differs a lot between a classic cPanel host and a managed WordPress platform. Here’s what actually changes on each side.

Step 1: Turn off the built-in trigger

In wp-config.php, above the line that reads /* That's all, stop editing! */, add:

define('DISABLE_WP_CRON', true);

This stops WordPress from spawning the loopback wp-cron.php request on every page load. It does not stop scheduled tasks from existing — it just stops them from running until something else triggers wp-cron.php on a schedule. Skip the next step and your scheduled posts, backups, and plugin sync jobs will simply stop firing.

Step 2: Add a real system cron job

Most cPanel-based hosts (InterServer, A2, standard shared plans generally) expose this under cPanel → Cron Jobs. Set it to run every 5–15 minutes, pointed at:

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

or, if the host prefers direct PHP execution over HTTP (usually faster, and doesn’t count against outbound bandwidth):

php /home/username/public_html/wp-cron.php >/dev/null 2>&1

Managed WordPress platforms handle this differently. Some (Kinsta, WP Engine) run system cron for you automatically the moment they detect DISABLE_WP_CRON is set, no dashboard step needed. Others expose a “scheduled tasks” toggle in their own panel instead of raw cPanel — check the host’s WP-specific dashboard before assuming you need to hunt for a cPanel cron tab that may not exist on that plan tier.

Step 3: Pick an interval that matches your actual needs

Site type	Recommended interval	Why
Blog/content site, few scheduled posts	15 min	Scheduled-post delay of up to 15 min is invisible to readers
Site with WooCommerce or membership plugins	5 min	Order-status transitions, subscription renewals, and stock sync often assume near-real-time cron
Site with a backup plugin running big scheduled jobs	Match to the plugin’s own scheduled backup time, not more frequent	Backups are usually self-scheduled inside the plugin; system cron just needs to be frequent enough to catch the trigger, not run every minute

Common mistake: disabling WP-Cron with no replacement

The single most common support ticket in this area is someone finding DISABLE_WP_CRON in a “performance tips” article, adding it, and stopping there. A month later scheduled posts stop publishing and nobody connects the two. If you disable the built-in trigger, the system cron job is not optional — it’s the other half of the same change.

How to verify it’s actually working

Install WP Crontrol (or check via WP-CLI with wp cron event list) and look at the “Next run” times on core events like wp_version_check or wp_scheduled_delete. If the “next run” time is in the past and stays in the past across multiple checks a few minutes apart, your real cron job isn’t reaching wp-cron.php — check the cPanel cron job log for a non-zero exit code, and confirm the path or URL in the cron command actually matches your account’s home directory or domain.

FAQ

Does disabling WP-Cron improve page speed? Marginally, and only on sites where visits are frequent enough that the loopback check itself becomes a measurable per-request cost. The bigger win is reliability — tasks run on schedule instead of “whenever a visitor happens to show up.”

Will this break anything by itself? No, as long as you complete both steps. Step 1 alone (with no system cron) is what breaks scheduled tasks.

Do I need shell/SSH access to set this up? No — cPanel’s Cron Jobs UI and most managed-WP dashboards handle it with no terminal access needed.

Verdict

This is a five-minute change with a real (if modest) reliability upside, and it’s one of the few “performance tips” that’s actually free of trade-offs when done correctly. The only way to get it wrong is stopping after step 1 — do both steps, verify with WP Crontrol, and move on.