WordPress runs its scheduled tasks (publishing scheduled posts, checking for updates, clearing transients, and anything plugins queue) through a file called wp-cron.php. On a busy site, the default way this file is triggered becomes a real performance problem. This guide explains why, and shows you how to switch WordPress over to a proper system cron so scheduled tasks still run reliably without the overhead.
Last reviewed: 27 July 2026, against current WordPress 6.x releases. WP-Cron behaviour has been stable across recent WordPress versions. This guide is written for Noiz hosting and complements, and does not replace, the official WordPress documentation linked below.
Official Documentation Reference
What is wp-cron.php and how does it work?
The wp-cron.php file is how WordPress handles scheduled events by default. Any function that relies on scheduling, such as core updates, plugin update checks, and scheduled post publishing, is handled through this file.
For this to work correctly, the file needs to run frequently, but no more than roughly once per minute. The problem is that WordPress does not use a system-level cron job out of the box. Instead, it triggers on incoming traffic: when a visitor requests a page, WordPress fires an additional request to wp-cron.php over HTTP(S) to check whether any scheduled task is due.
Why is this a problem?
On a small site with only a handful of visitors per hour, this approach works fine. On a medium or larger site, or on any site that attracts a lot of bot traffic and vulnerability scans, it does not. Every one of those requests can spawn a second internal request to wp-cron.php, so the site more than doubles the load it places on itself. In effect, WordPress ends up DDoS-ing itself: pages slow down, and the web server carries needless extra load.
There is a second, subtler issue. Because WP-Cron only runs when someone visits, scheduled tasks on a low-traffic site can run late or not at all, so a post scheduled for 09:00 might not publish until the next visitor arrives.
The better approach: disable WP-Cron and use a system cron
The fix is to turn off the built-in trigger and let the server run WordPress's scheduled tasks on a fixed timetable instead. This keeps scheduled tasks running predictably while removing the per-request overhead. Running the job through the shell, rather than over HTTP(S), also avoids the extra web-server memory a full HTTP request would consume. If you would rather not touch configuration files at all, a Noiz Managed WordPress plan applies this optimisation for you by default.
Step 1: Disable the built-in WP-Cron
Edit your wp-config.php file and add the following line above the /* That's all, stop editing! Happy publishing. */ comment:
define( 'DISABLE_WP_CRON', true );The setting must sit above that line so it takes effect before WordPress finishes loading; placed after it, the define is read too late to have any effect. The wp-config.php file lives in your site's root directory, typically public_html, though the exact path varies by host and control panel.
Step 2: Set up a system cron
With the built-in trigger disabled, add a scheduled task on the server to call wp-cron.php directly. Running it every 5 to 15 minutes suits most sites; increase the frequency only if you depend on tightly timed scheduled events. A typical command, run through the shell, looks like this:
*/5 * * * * php /home/example/public_html/wp-cron.php >/dev/null 2>&1Replace the path with the real path to your site's wp-cron.php. Exactly how you add this depends on your control panel:
- ISPConfig
- Plesk
- cPanel
- Ubuntu command line: on a managed cloud server, a Noiz administrator can set this up for you on request.
Why it is worth doing
WordPress powers a huge share of the web, which makes the default scheduling behaviour a costly compromise at scale. It adds avoidable load to individual sites and, multiplied across a hosting network where many sites use the same resource-heavy method, to the infrastructure as a whole. Moving to a system cron removes that overhead and makes scheduled tasks more reliable at the same time.
If you would rather not edit configuration files yourself, a Noiz Managed WordPress plan handles this change by default, along with the other performance and maintenance benefits that come with managed hosting. Most site owners notice a clear speed improvement once WP-Cron is running from the system scheduler.
