WordPress automatically performs numerous recurring tasks in the background. These include, for example, scheduled posts, automatic updates, maintenance tasks, sending certain emails, or time-controlled actions by plugins. For these tasks, WordPress uses the so-called default WP-Cron System.
However, WP-Cron is not a true server cron job. Instead, WordPress attempts to check whether scheduled tasks need to be executed whenever a page is loaded. On high-traffic websites, this can cause unnecessary additional processes. On websites with very little visitor traffic, on the other hand, the opposite problem occurs: scheduled tasks may be executed late because no page is loaded for a long time.
A technically cleaner solution is to disable the automatic WP cron invocation of WordPress and instead use a real cron job on the server to set up. With CURIAWEB web hosting, you can configure this via cPanel.
Important: Never simply disable WP-Cron in WordPress. If you disable WP-Cron, you should subsequently set up a server cron job that regularly executes the scheduled WordPress tasks.
What is WP-Cron? #
WP-Cron is WordPress's internal system for scheduled tasks. The name is somewhat misleading because, technically, it is not a classic operating system cron service.
WordPress uses WP-Cron, for example, for:
- scheduled blog posts
- automatic WordPress updates
- Plugin and Theme Tasks
- deleting temporary data
- scheduled emails
- WooCommerce tasks
- Backup plugins
- Caching and optimization tasks
- Newsletter and Marketing Plugins
- background processes registered by other plugins
Plugins can register their own tasks in the WordPress cron system. Therefore, the number of scheduled processes on a large WordPress website can be significantly higher than on a simple installation.
How does WP-Cron work by default? #
During a normal WordPress request, WordPress checks whether any scheduled cron tasks are pending execution. Put simply, WP-Cron is therefore triggered by activity on the website.
The WordPress file responsible for this is:
wp-cron.php
This method has a major advantage: WordPress also works with it on hosting systems where users cannot set up their own server cron jobs.
It also has disadvantages.
Why can WP-Cron be problematic? #
WP-Cron is completely sufficient for many websites. Therefore, there is no reason to fundamentally deactivate WP-Cron on every WordPress installation.
However, for certain websites, a real server cron job can be more reliable and efficient.
Problem 1: High page views #
On high-traffic websites, the WP-cron check is triggered very frequently. While WordPress has mechanisms to limit parallel executions, the standard procedure can still cause unnecessary additional work.
A server cron job runs the check against it at a fixed interval, for example every five minutes.
Problem 2: Very few page views #
On a website with little or no visitor traffic, the opposite can happen. If no one visits the website, the trigger for WP-Cron may be missing.
Therefore, a task scheduled for 08:00 does not necessarily have to be executed at exactly 08:00. It can be triggered the next time a suitable call occurs.
A real server cron job, on the other hand, operates independently of whether anyone is currently visiting the website.
Note: WP-Cron is not a fundamentally bad system. For small websites, the default WordPress configuration is often completely sufficient. A real cron job becomes particularly interesting when scheduled tasks need to be executed more reliably or with more control.
When is a real cron job worth it? #
The transition can be particularly useful for websites that perform many time-controlled or resource-intensive tasks.
Typical examples are:
- larger WordPress websites
- WooCommerce stores
- websites with many visitors
- Websites with very little visitor traffic, but important scheduled tasks
- Websites with automated backups
- Newsletter systems
- Import and export processes
- regular synchronizations
- Plugins with numerous background tasks
If your website works without issues and does not use time-critical background processes, you don't need to replace WP-Cron just on principle.
Step 1: Create backup #
To deactivate the automatic WP-Cron call, the WordPress configuration file wp-config.php be processed.
Therefore, create a backup of the file before making the change, or better yet, a complete backup of your WordPress website.
The file wp-config.php is among the most important files of a WordPress installation. A syntax error can cause WordPress to no longer load correctly.
Warning: Edit the file
wp-config.phpcarefully. Even a single incorrect character or a wrongly inserted PHP statement can lead to an error on the website.
Step 2: Open wp-config.php #
The file wp-config.php is usually located in the root directory of your WordPress installation.
With CURIAWEB, for example, you can use the File Manager in cPanel access your WordPress files.
In a typical main domain installation, WordPress is often located at:
public_html
Depending on the domain and directory structure, however, WordPress can also be installed in a different directory.
Open the file there:
wp-config.php
Step 3: Disable WP-Cron in WordPress #
Add the following line to the file wp-config.php a
define( 'DISABLE_WP_CRON', true );
The instruction should be inserted before the line that metaphorically marks the end of editing the WordPress configuration.
Depending on the language version or WordPress version, the comment may be phrased differently. The crucial point is that the constant is defined within the actual WordPress configuration and not after the WordPress core components are loaded.
Then save the file.
With:
define( 'DISABLE_WP_CRON', true );
you prevent WordPress from continuing to automatically trigger WP-Cron via normal page views.
Important: The planned WordPress tasks were not deleted with this. You have merely deactivated the default automatic trigger. Therefore, we now need a server cron job.
Step 4: Open Cron jobs in cPanel #
Log in to your CURIAWEB customer center and open your hosting via the direct cPanel Login.
Alternatively, you can open cPanel via your existing direct access.
Search in cPanel for:
Cron jobs
This function allows commands to be executed automatically by the server at specific times or at regular intervals.
How often should WordPress Cron be executed? #
For many normal WordPress websites, an interval of 5 to 15 minutes Sufficient.
Which interval makes sense depends on the website. A WooCommerce store or a website with time-critical automations may have different requirements than a small business website.
For example, a cron job every five minutes means:
*/5 * * * *
A cron job every 15 minutes:
*/15 * * * *
You don't need to run a cron job every minute unless there is a specific technical reason to do so. Unnecessarily short intervals simply generate additional processes.
Recommendation: For a standard WordPress website, an interval of 5 to 15 minutes is a reasonable starting point. Only use shorter intervals if your website or a specific plugin actually requires it.
Step 5: Set up server cron job for WordPress #
The server now needs the file wp-cron.php call regularly.
There are various technical options for this. Which variant is used depends, among other things, on the hosting environment and the desired method of invocation.
One possibility is an HTTP call to the WordPress cron file. The basic call is:
Replace your-domain.ch through your actual domain.
In a server cron job, the URL can be called using an available command-line tool, for example. What is important in this regard is not the tool itself, but that wp-cron.php is reliably executed at the desired interval.
Because server paths and available commands can vary depending on the hosting configuration, you should not blindly copy a cron command from an external tutorial.
Notice for CURIAWEB customers: If you are unsure which command to use for your hosting, contact CURIAWEB support. We can tell you which cron job configuration is suitable for your hosting.
Why don't we just specify some cron command? #
On the internet you will often find commands with wget, curl or a direct PHP call. Such examples can work, but they are not automatically identical for every hosting environment.
For example, a direct PHP call requires the correct server path to the WordPress installation and, if applicable, the correct PHP binary path. An HTTP call, in turn, depends on the domain, HTTPS configuration, and server environment.
Therefore, a guide with a fictional or unfamiliar server path would be worse than a clean configuration for the hosting actually used.
WP-Cron and PHP version #
If the cron job runs WordPress directly via PHP on the server, care should be taken to ensure that the PHP version used matches the WordPress installation.
This is particularly relevant if multiple PHP versions are available on a hosting account or if different websites use different PHP versions.
A cron job should not accidentally use a different PHP version than the website if this causes incompatibilities with WordPress, themes, or plugins.
Does WordPress still work after being deactivated? #
Yes. The setting DISABLE_WP_CRON does not deactivate WordPress itself and also does not fundamentally prevent the execution of scheduled tasks.
It prevents the default automatic WP-Cron execution on website visits.
If the server cron job is set up correctly, it will wp-cron.php instead, it is triggered regularly by the server and WordPress can process due tasks.
What happens if no server cron job is set up? #
This is precisely where one of the most common mistakes in this optimization lies.
If you:
define( 'DISABLE_WP_CRON', true );
set up, but do not configure an alternative cron job, scheduled WordPress tasks may fail to run.
Depending on the website, the following problems may then occur, for example:
- Scheduled posts are not being published
- Automatic tasks from plugins are not running
- Backups are not being created as planned
- Certain emails are sent with a delay or not triggered at all.
- WooCommerce background processes may be impaired
- Maintenance and cleanup tasks are being neglected
Warning:
DISABLE_WP_CRONWithout a working replacement cron job, this is not performance optimization, but rather a faulty configuration.
How can I check if WordPress cron is working? #
After setup, you should check whether scheduled tasks are actually being executed.
An easy way is a scheduled WordPress post. Create a test post and schedule its publication for a future time.
If the post is published after the cron job runs, this is a first indication that scheduled WordPress tasks are being processed.
For a more detailed analysis, there are also WordPress plugins that allow you to view and check registered cron events. Such tools are particularly helpful when troubleshooting.
WP-Cron in WooCommerce #
Special caution is required with WooCommerce. An online store performs numerous background tasks, and WooCommerce additionally uses for many processes the Action Scheduler-System.
This is used, for example, by WooCommerce itself and various extensions for background processes. The reliable execution of scheduled WordPress tasks also plays an important role here.
For a production WooCommerce store, you should therefore not disable WP-Cron without immediately setting up a working server cron job and subsequently checking that it functions properly.
Does a real cron job automatically make WordPress faster? #
Not necessarily.
Replacing the default WP-Cron trigger can make the execution of scheduled tasks more controllable and, on certain websites, reduce unnecessary cron calls during normal page visits.
However, it is not a universal trick that suddenly makes every WordPress website significantly faster.
For the performance of a WordPress website, hosting resources, PHP, database, caching, themes, plugins, images, and the actual application are, among other things, much more important.
WP-Cron should therefore be optimized for a technical reason and not because some checklist claims that it must be deactivated in principle.
Reactivate WP-Cron #
If you want to revert to the default WordPress behavior, open the file wp-config.php and remove the previously inserted line:
define( 'DISABLE_WP_CRON', true );
You should then also check whether the additionally configured server cron job is still required.
Avoid an uncontrolled dual configuration where you make changes without knowing which mechanism is actually executing the cron jobs.
How to configure WP-Cron correctly in CURIAWEB #
With CURIAWEB web hosting, you can set up a real cron job via cPanel. This allows you to control the execution of scheduled WordPress tasks independently of actual page views.
The correct procedure always consists of two related steps:
- the automatic WP-Cron call in
wp-config.phpwithDISABLE_WP_CRONDeactivate. - Set up a working server cron job that triggers WordPress regularly.
If you are unsure about the server path, PHP version, cron command, or interval, contact CURIAWEB support before disabling the default configuration.
Recommendation: Do not change WP-Cron simply because you want to perform a supposed WordPress optimization. If your website is working without issues, the default configuration may be completely sufficient. For shops, automations, or time-critical tasks, however, a real server cron job can be the technically better solution.
Summary #
WP-Cron is WordPress's internal scheduling system and is triggered by website visits by default. This works without issues for many websites, but it is not a true time-based server cron job.
If you want to replace WP-Cron with a real cron job, you add define( 'DISABLE_WP_CRON', true ); into the file wp-config.php and then set up a server cron job in cPanel that wp-cron.php executes regularly. For many websites, an interval of about 5 to 15 minutes is a sensible starting point.
The combination of both steps is crucial. Merely disabling WP-Cron without setting up a working replacement can impair scheduled posts, backups, plugin tasks, and other WordPress processes.