---
title: "How to Disable wp-cron.php and Use a System Cron in WordPress"
description: "Stop wp-cron.php firing on every page load by disabling WP-Cron in wp-config.php and running WordPress scheduled tasks from a system cron job instead."
url: "https://docs.noiz.ie/wordpress/how-to-disable-wp-cronphp-and-use-a-system-cron-in-wordpress/"
section: "WordPress"
categories:
  - "Applications > WordPress"
last_reviewed: "27 July 2026, against current WordPress releases"
---

# How to Disable wp-cron.php and Use a System Cron in WordPress

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 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

- [WordPress Plugin Handbook: WP-Cron](https://developer.wordpress.org/plugins/cron/)
- [Hooking WP-Cron Into the System Task Scheduler](https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/)

## 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>&1
```

Replace the path with the real path to your site's `wp-cron.php`. Exactly how you add this depends on your control panel:

- [ISPConfig](/ispconfig/how-to-create-a-cron-job-in-ispconfig/)
- [Plesk](/plesk/how-to-create-scheduled-tasks-in-plesk/)
- [cPanel](/cpanel/how-to-create-a-cron-job-in-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.

---
Source: https://docs.noiz.ie/wordpress/how-to-disable-wp-cronphp-and-use-a-system-cron-in-wordpress/