How to Disable WP-Cron in WordPress?
WP-Cron is the part of WordPress quietly running in the background every time someone loads a page on your site, checking whether a scheduled post needs publishing, a plugin needs to check for updates, or a backup needs to run. It works fine on most sites. On a high-traffic site or a cramped shared hosting plan, it can quietly become one of the bigger drags on performance, because it fires on every single page load rather than on an actual schedule.
This guide covers what WP-Cron actually does, why disabling it helps in the right situations, and the exact steps, including the code, to disable it safely and replace it with a real server-side cron job.
What WP-Cron Actually Is
WP-Cron is WordPress’s built-in task scheduler, handling things like publishing scheduled posts, checking for plugin and theme updates, sending scheduled emails, and running cleanup tasks that plugins register. Unlike a true system cron job, which runs on a fixed schedule regardless of traffic, WP-Cron is pseudo-cron: it checks whether any scheduled task is due every time a visitor loads a page, and runs anything that’s overdue right then.
That design is what makes it convenient (no server access required, works on virtually any host) and also what makes it a problem at scale. Every page load carries the overhead of that check, and on a busy site, that adds up to a real, measurable cost.
It’s worth being clear about what “disabling WP-Cron” actually means before going further, since the phrase gets used loosely. Disabling it doesn’t turn off scheduled tasks entirely; it stops WordPress’s own page-load-triggered check from being the thing that runs them. The tasks themselves, publishing a scheduled post, checking for an update, still need something to trigger them. That’s the whole reason Step 2 below matters as much as Step 1.
Related reading: 10 best software for iPhone tutorial screen recording.
Why You Might Want to Disable It
1. Server Load
WP-Cron runs its check on every page load. On a high-traffic site, that means the scheduler check fires hundreds or thousands of times an hour, whether or not anything is actually due to run. On a shared hosting plan with limited CPU allocation, this overhead alone can measurably slow down page response times.
2. Predictable Timing
Because WP-Cron only checks for due tasks when a visitor shows up, a task scheduled for 3 a.m. on a low-traffic site might not actually run until the first visitor arrives at 7 a.m. A real server cron job runs at the exact time you set, regardless of traffic.
3. Reliability
A site with genuinely no traffic for a stretch of time (a staging site, a site in a low season, a site recovering from an outage) can end up with scheduled tasks that simply never fire, because nothing ever triggers the check. Server-side cron doesn’t have this problem.
4. Resource Efficiency
A real cron job runs once, does its job, and exits. WP-Cron’s check-on-every-page-load model means the same overhead gets paid repeatedly throughout the day, whether or not it’s needed.
5. Fewer Collisions
On a site with many plugins each registering their own scheduled tasks, WP-Cron occasionally triggers several tasks in the same request, competing for the same PHP process and memory. A properly spaced server cron job reduces how often that pileup happens.
The Risks Worth Knowing First
Missed tasks if the replacement cron job is misconfigured. Disabling WP-Cron without setting up a working server cron job in its place means scheduled posts, updates, and emails simply stop running. This is the single most common way this change goes wrong.
A steeper setup step. Editing wp-config.php and configuring a server cron job requires a bit more comfort with hosting tools than most WordPress tasks. It’s not difficult, but it’s not a settings-panel toggle either.
Hosting plan limitations. Not every hosting plan exposes cron job configuration, particularly on the cheapest shared tiers. Check your host’s control panel or ask support before committing to this change.
None of these risks are a reason to avoid the change outright. They’re a reason to do the two steps together, in order, and verify the result, rather than disabling WP-Cron and assuming the rest will sort itself out.
How to Disable WP-Cron and Replace It With a Real Cron Job
Step 1: Turn Off WP-Cron in wp-config.php
Connect to your site with an FTP client (FileZilla is a common free choice) or use the File Manager in your hosting control panel. Open wp-config.php in the root directory of your WordPress installation.
Add this line above the comment that says “That’s all, stop editing! Happy blogging.”:
define( 'DISABLE_WP_CRON', true );Save the file. This stops WordPress from running its own scheduler check on every page load. At this point, nothing will trigger scheduled tasks until you set up a replacement in Step 2, so don’t stop here.
Step 2: Set Up a Real Server Cron Job
Log into your hosting control panel and find the Cron Jobs section (cPanel, Plesk, and most managed WordPress hosts all expose this somewhere in the dashboard). Create a new cron job set to run every 15 minutes, which matches WordPress’s own default scheduling interval closely enough for nearly every site.
The command depends on what your host supports. If your host allows curl or wget to hit a URL, use:
curl https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1or, if wget is what’s available instead:
wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1Replace yourdomain.com with your actual domain. If your host instead offers a direct PHP-CLI cron option (common on managed WordPress hosts), the equivalent command usually looks like:
php /home/yourusername/public_html/wp-cron.php >/dev/null 2>&1with the exact file path adjusted to match your server’s actual directory structure, which your host’s support team can confirm if you’re not sure.
Related reading: should I remove Polyfill from WordPress, another common performance question with a similarly specific, technical answer.
Step 3: Verify It’s Actually Working
Don’t just assume the cron job is running. Schedule a test post a few minutes out and confirm it publishes on time. A free WP-Cron testing plugin, or a simple check of your scheduled posts list an hour later, confirms the replacement is actually firing instead of silently failing.
A tool like WP Crontrol, installed temporarily even if you remove it afterward, gives a direct view of every task WordPress has scheduled and exactly when each one is next due to run. Comparing that list against what actually executes over the next hour is the clearest way to catch a misconfigured cron job before it causes a real problem, rather than discovering the issue days later when a scheduled post never went live.
Weighing the Trade-Off
What you gain: faster page loads by removing the per-visit scheduler check, tasks that run at the exact time you set regardless of traffic, and cron jobs that keep working even during a quiet traffic period.
What it costs you: a one-time setup step that requires editing a core file and configuring your host’s cron system, plus an ongoing (small) responsibility to notice if the cron job ever silently stops working, since nothing will alert you automatically the way a broken plugin usually does.
Mistakes That Break This Setup
Disabling WP-Cron and stopping there. This is by far the most common mistake. The constant in wp-config.php only turns off WordPress’s own scheduler check; it does nothing to replace it. Skip Step 2 and scheduled posts, plugin updates, and backup jobs simply stop running, often silently, until someone notices weeks later that a scheduled post never went live.
Setting the cron interval too far apart. A cron job that only runs once a day means time-sensitive tasks, a scheduled post meant to go live at a specific hour, a subscription renewal check, can end up hours late. Fifteen minutes is a safe default for most sites; time-sensitive stores or membership sites may want five or ten.
Using the wrong URL in the cron command. A typo in the domain, a missing https, or forgetting the ?doing_wp_cron query parameter means the cron job runs but hits nothing useful. Test the URL directly in a browser first; it should return a blank or near-blank page rather than a 404 or an error.
Forgetting this exists after a site migration. The wp-config.php edit travels with a site migration, but the server-side cron job usually doesn’t, since it lives in the old host’s control panel, not in WordPress itself. A site that moves hosts and forgets to recreate the cron job ends up with WP-Cron disabled and nothing running in its place, which is a worse state than never having disabled it at all.
Alternatives to a Full Disable
A complete disable-and-replace isn’t the only option. A few middle-ground approaches are worth knowing about before committing to server-level configuration.
Adjusting the cron check frequency with a plugin. Several free WordPress plugins let you throttle how often WP-Cron’s check runs without touching wp-config.php or your host’s control panel at all. This captures some of the performance benefit with none of the setup complexity, though it’s less precise than a true server cron job.
Triggering WP-Cron via an external uptime monitor. Some site owners point an existing uptime-monitoring service at the wp-cron.php URL on a schedule, which effectively creates a lightweight external trigger without needing direct server cron access. This works reasonably well for sites on hosts that don’t expose cron job configuration at all.
Leaving WP-Cron as-is but optimizing what runs on it. Sometimes the actual problem isn’t WP-Cron itself but a specific poorly optimized plugin task registered to run too frequently. Auditing what’s actually scheduled, using a plugin like WP Crontrol to see the full list, sometimes solves the performance problem without touching the scheduling system at all.
Common Questions
Will disabling WP-Cron break my scheduled posts?
Only if you disable it without setting up a replacement cron job. Done correctly, with both steps completed, scheduled posts publish exactly as before, often more reliably since they no longer depend on a visitor happening to load the site at the right moment.
How do I know if WP-Cron is actually slowing down my site?
Check server response times during peak hours with a profiling tool like Query Monitor, which breaks down exactly how much time each part of a page load consumes. If WP-Cron’s check is a negligible fraction of total load time, it’s probably not your bottleneck. On busier sites it often shows up as a small but consistent tax on every single request.
Can I use a plugin instead of editing wp-config.php directly?
Yes. Several performance and cron-management plugins offer a toggle that does the same thing as the wp-config.php constant, without requiring FTP access. The underlying mechanism is identical; the plugin route just avoids editing a core file directly, which some site owners prefer.
What happens to WP-Cron tasks if my server cron job fails silently?
Nothing runs, and nothing alerts you by default. This is the main risk of this whole setup. Testing the replacement cron job after setup, and periodically confirming scheduled posts are still publishing on time, is the only real safeguard against a silent failure going unnoticed for weeks.
Does this apply to WordPress multisite the same way?
The core mechanism is the same, but a multisite network runs WP-Cron checks per subsite, which multiplies the overhead on a large network. The server cron job replacement also needs to hit each subsite’s wp-cron.php, or use WordPress’s multisite-aware cron handling, rather than a single site’s URL.
Is This Actually Worth Doing for Your Site?
For a low-traffic blog or a brochure site with a handful of visitors a day, WP-Cron’s default behavior is rarely worth the effort of replacing. The overhead it adds per page load is small, and the convenience of not touching server configuration outweighs the marginal performance gain. A site owner managing their own small business site, with no developer on retainer, is often better served leaving the default behavior alone and focusing optimization effort somewhere with a bigger payoff, like image compression or a caching plugin.
For a high-traffic site, an online store processing scheduled sales or subscription renewals, or any site on a resource-limited shared hosting plan, the calculation flips. The performance gain from switching to a real cron job is measurable, and the reliability improvement, tasks running exactly when scheduled instead of whenever the next visitor happens to load a page, matters more as the site’s operations get more time-sensitive.
A digital product store running scheduled sales, license expirations, or subscription renewal reminders is a particularly good candidate, since those tasks carry a direct revenue consequence when they run late. A renewal reminder that fires six hours behind schedule because no visitor happened to trigger WP-Cron in that window is a small but real cost that a server-side cron job removes entirely.
A quick way to check if this is worth doing on your own site: look at your server’s response time during peak traffic hours using a tool like Query Monitor, and see how much of that time WP-Cron’s check is consuming. If it’s a negligible fraction of total load time, the change probably isn’t worth the setup effort yet. If it’s showing up as a meaningful chunk, it’s a strong candidate for the switch described above.
How This Interacts With Caching
A full-page caching setup complicates WP-Cron in a way that’s easy to miss. If your site serves cached HTML for most visitors, the actual PHP request that would trigger WP-Cron’s check may rarely fire at all, since cached pages don’t execute WordPress’s PHP code the same way a fresh page load does. On a heavily cached site, this can mean WP-Cron effectively stalls on its own, quietly, without anyone disabling it deliberately.
This is actually one of the strongest arguments for switching to a real server cron job on any site running a caching plugin. Rather than hoping enough uncached requests slip through to keep the scheduler alive, a dedicated cron job guarantees scheduled tasks run on time regardless of how aggressively the rest of the site is cached. Sites running a full-page cache plugin and still relying on default WP-Cron behavior are a common source of the “why didn’t my scheduled post publish” support ticket.
Checking Your Work a Month Later
The setup itself takes fifteen minutes. The part that actually determines whether it was worth doing is what happens over the following weeks. Set a calendar reminder to check back in a month: confirm scheduled posts have been publishing on time, that plugin update checks are still running, and that the cron job in your hosting control panel is still active rather than silently disabled after a routine server maintenance window.
Hosting providers occasionally reset or clear cron jobs during account migrations, plan changes, or server maintenance without much warning. A site that had this working perfectly for six months can suddenly stop running scheduled tasks after an unrelated hosting change, and because nothing throws a visible error, it’s easy for that to go unnoticed until something time-sensitive, an expiring coupon, a scheduled product launch, quietly misses its window.
Interesting reads:
10 best WordPress cache plugins
15+ must-have WordPress plugins for a high-performance website