Author: onetwothreeadmin

WordPress cron is a lie. It’s not a scheduled task runner—it’s a script that fires when someone visits your site. If nobody visits for an hour, nothing runs for an hour. If fifty people hit your homepage at once, that script might try to run fifty times simultaneously.

That’s why your admin dashboard sometimes loads slowly, or why your scheduled posts don’t publish at the exact minute you set. Understanding what WordPress cron actually does—and when to replace it—matters once you’re running a content operation that depends on predictable publishing and performance.

What WordPress cron actually runs

Every WordPress install has a default set of cron jobs baked in. These include:

• Checking for plugin and theme updates
• Publishing scheduled posts
• Clearing expired transients (temporary data stored in your database)
• Sending pingbacks and trackbacks
• Running database cleanup tasks

Plugins and themes add their own jobs on top of this baseline. Newsletter plugins schedule digest sends. Backup plugins queue nightly snapshots. SEO plugins refresh sitemaps. Social-sharing tools check for new posts to auto-tweet.

You can see every scheduled task by installing the WP Crontrol plugin. It lists every job, its recurrence interval, and the function it calls. On a typical site with a dozen active plugins, you’ll find twenty to forty jobs running hourly, daily, or weekly.

Why it slows your site down

WordPress cron fires on page load. When a visitor requests a page, WordPress checks if any cron jobs are due. If they are, it spawns a background HTTP request back to itself to process them.

That works fine for low-traffic blogs. But once you’re running a content site with consistent traffic, you hit two problems:

Multiple simultaneous triggers. If ten people load your homepage within the same second, WordPress might spawn ten parallel cron processes. Those processes compete for database connections and CPU. Your server slows down. Page load times spike.

Cron jobs that block rendering. Some poorly-coded plugins don’t spawn the background request correctly. Instead, they run their cron tasks inline—before the page finishes loading. A five-second backup task means a five-second delay before your visitor sees anything.

The standard fix is to disable WordPress cron entirely and replace it with real server-level cron.

How to replace it with real cron

Disabling WordPress cron takes one line in your wp-config.php file:

define('DISABLE_WP_CRON', true);

Add that above the line that says “That’s all, stop editing!” and save the file. WordPress will stop checking for due tasks on every page load.

Now you need to tell your server to run those tasks instead. Most shared hosts and managed WordPress hosts (including BigScoots) let you add cron jobs through cPanel or a similar control panel.

Create a new cron job that runs every five or ten minutes, pointing to:

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

Or, if your host supports it:

php /path/to/your/wordpress/wp-cron.php

The first version uses HTTP to trigger the cron script, just like WordPress does—but on a predictable schedule instead of on every page load. The second version runs it directly via PHP, which is faster and doesn’t consume an HTTP request slot.

Check your host’s documentation or ask support which syntax to use. Most managed WordPress hosts already handle this for you if you disable WP_CRON in config.

When to leave WordPress cron enabled

If your site gets fewer than a hundred visits per day, the default behavior is fine. The overhead is negligible, and you avoid the hassle of configuring server-level cron access.

If you’re on a staging site or local development environment, leave it on. You need to visit the site to trigger tasks anyway, and setting up real cron for ephemeral environments isn’t worth it.

But if you’re publishing on a schedule, running automated workflows, or seeing unexplained slowdowns during traffic spikes, disable WP_CRON and hand the job to your server. You’ll get predictable task execution and faster page loads.

One non-obvious tip: After you switch to real cron, check WP Crontrol again in a week. Some plugins re-register their tasks incorrectly and create duplicates. If you see the same job listed twice with different intervals, delete the duplicate manually. It won’t break anything—the plugin will recreate the correct version on its next run.

If this helped, subscribe to One Two Three Send for weekly breakdowns of the tools and infrastructure that actually matter when you’re running a content business solo.

Most WordPress hosting panels now ship with a one-click staging environment. You spin up a copy of your live site, test a plugin update or theme tweak, and push changes once you’re confident nothing breaks.

It’s a smart workflow. But staging isn’t a perfect safety net, and treating it like one leads to false confidence and real downtime.

Here’s what staging environments actually protect you from—and the failure modes they quietly ignore.

What staging catches reliably

Staging environments excel at isolating code-level conflicts. If you’re updating a plugin that hasn’t been touched in eighteen months, a staging site will surface PHP errors, broken shortcodes, and layout shifts before they hit your readers.

You’ll also catch visual regressions. A theme update that changes your header structure or removes a custom CSS class will show up immediately. Same with a page builder update that reformats your landing pages.

And staging is useful for workflow rehearsal. If you’re migrating from one form plugin to another, or restructuring your permalink settings, you can walk through the entire process without risking your live site’s SEO or user experience.

Most managed WordPress hosts—BigScoots included—let you clone your production database and files in under a minute. The staging site runs on the same server stack, so you’re testing against a nearly identical environment.

What staging misses entirely

Staging environments don’t replicate third-party API behaviour. If your site connects to a payment processor, email service, or analytics platform, those integrations either won’t work in staging (because the API keys are sandboxed) or they’ll work differently (because staging traffic doesn’t match production load).

You also can’t test caching behaviour accurately. Most staging environments disable caching plugins or CDN layers by default. That means a change that works perfectly in staging might still break when it hits your live site’s edge cache or object cache.

And staging won’t catch performance problems under real traffic. A database query that runs in 200ms on a staging site with ten test posts might balloon to two seconds on a production site with ten thousand posts and a dozen concurrent users.

Finally, staging environments don’t protect you from deployment errors. If your host’s push-to-live function skips a file, overwrites a manual edit, or fails to flush the cache, you won’t know until it’s live.

When to test in staging—and when to skip it

Use staging for major version updates: WordPress core, your theme, or any plugin that touches your site’s critical path. These are high-risk changes that can break layouts, disable forms, or trigger fatal errors.

Also use staging for structural changes: switching themes, adding a new page builder, or enabling a plugin that injects code into every page. These changes touch too many files to trust without rehearsal.

But skip staging for low-risk content edits. If you’re tweaking a blog post, updating a menu link, or uploading a new image, you’re adding friction without reducing risk. Make the change live, check it in an incognito window, and move on.

And don’t rely on staging for plugin settings changes. Most plugins store settings in the database, and pushing changes from staging to production will either overwrite your live settings or skip them entirely. Test those directly in production—ideally during low-traffic hours.

The non-obvious tip: test the push itself

Most hosting platforms offer a “push to live” button that syncs your staging database and files back to production. But that push process isn’t guaranteed to be lossless.

Before you push a major update, export your live database and store a backup locally. Then push from staging and immediately check three things: your homepage loads, your contact form works, and your most recent blog post displays correctly.

If any of those fail, you’ll know within seconds—not hours later when a reader emails you.

And if your host doesn’t offer staging environments, don’t build one manually. The risk of misconfiguring file permissions, breaking symlinks, or syncing the wrong database table outweighs the benefit. Either upgrade to a host that includes staging as a managed feature, or test updates during off-peak hours and keep a recent backup within reach.

One Two Three Send covers WordPress hosting, email infrastructure, and every other tool solo operators rely on. Subscribe to get one operator-focused article every day—no fluff, no affiliate spam, just the details that matter.