Run WordPress WP-Cron from Server Cron: DISABLE_WP_CRON and crontab

This article is a localized edition of the Japanese original. Read the Japanese original

WordPress scheduled posts, periodic plugin backups, update checks and similar tasks run through a mechanism called WP-Cron. WP-Cron is not a real cron (the operating system's task scheduler). It runs overdue tasks only when someone visits the site.

That leads to the following:

• On low-traffic sites, scheduled posts and periodic tasks run later than planned
• On high-traffic sites, a WP-Cron check runs on every page view

This article shows how to decouple WP-Cron from page views and run it at fixed intervals from the server's cron. The official WordPress Plugin Handbook also describes calling wp-cron.php from the system task scheduler.

Step 1: Stop WP-Cron from starting on page views

Open wp-config.php and add the following line above /* That's all, stop editing! Happy publishing. */.

define( 'DISABLE_WP_CRON', true );

This setting only stops "starting WP-Cron as a side effect of page views". If you call wp-cron.php directly, scheduled tasks still run as before.

If you add only this setting and forget step 2, scheduled posts, backups and other periodic tasks stop running. You can also register the cron job in step 2 first and add this setting afterwards.

Step 2: Register it in the server’s cron

There are three ways to call WP-Cron. Pick one that works on your server.

Which user’s crontab to edit

On a VPS, register the job in the crontab of the same user as the web server (www-data for Apache or Nginx on Ubuntu / Debian). If it runs as root, files created by plugins end up owned by root, and WordPress may not be able to modify them later.

sudo crontab -u www-data -e

On shared hosting, register the command in the control panel's cron settings screen or similar. Check your host's documentation for the PHP path and the location of the document root.

Method A: Run it with WP-CLI

This example runs every overdue task every 5 minutes. Set --path to the directory where WordPress is installed.

*/5 * * * * /usr/local/bin/wp --path=/var/www/html cron event run --due-now --quiet

The path to wp differs between servers, so check it with which wp. Cron runs with a minimal PATH environment variable, so write commands as full paths starting with /.

Method B: Run wp-cron.php with PHP

*/5 * * * * /usr/bin/php /var/www/html/wp-cron.php > /dev/null 2>&1

Check the PHP path (/usr/bin/php) with which php. Shared hosts sometimes provide a separate path for each PHP version.

Method C: Request wp-cron.php over HTTP

*/5 * * * * curl -s -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron"

Replace the URL with your own site. This method goes through the web server, so if the site uses Basic authentication or an IP restriction, make sure requests from the server itself are not refused.

Choosing the interval

The shortest recurrence WordPress core provides is hourly (hourly). Scheduled posts, however, can be set to the minute, so running every 5 minutes keeps delays to roughly 5 minutes at most. Some plugins register tasks with shorter intervals, so also check the documentation of the plugins you use.

Step 3: Check that it works

If WP-CLI is available, you can list scheduled tasks and their next run times.

sudo -u www-data wp --path=/var/www/html cron event list

In the next_run_relative column (time until the next run), look for tasks that stay overdue (for example, ones that keep showing "now"). If overdue tasks are still there a few minutes after you registered the cron job, cron may not be running.

You can also run it once by hand to see whether any errors appear.

sudo -u www-data wp --path=/var/www/html cron event run --due-now

wp cron test checks whether "starting WP-Cron on page views" works. It returns an error when DISABLE_WP_CRON is true, so it can't be used to check the setup in this article.

Logging the output

If you're not sure it is working, temporarily write the output to a file. Put the log file somewhere the cron user can write to.

*/5 * * * * /usr/local/bin/wp --path=/var/www/html cron event run --due-now >> /var/www/wp-cron.log 2>&1

In crontab, % is treated as a newline, so if you use % (for example in a dated file name), write it as \%. Once you've found the cause, switch back to the original line so the log doesn't keep growing.

On multisite

On multisite, WP-Cron schedules are stored per site. This example uses WP-CLI to run every site in turn.

*/5 * * * * /usr/local/bin/wp --path=/var/www/html site list --field=url | xargs -I {} /usr/local/bin/wp --path=/var/www/html cron event run --due-now --url={} --quiet

Things to keep in mind

• Revert the setting when you remove the cron job: When you move servers or stop the cron job, also remove DISABLE_WP_CRON from wp-config.php or set it to false. Otherwise periodic tasks stay stopped.
• Avoid overlapping with heavy tasks: If you have long-running tasks such as backups, don't make the interval too short.
• Don't call plugin files directly: Plugin tasks are registered with WP-Cron, so calling wp-cron.php runs them. There is no need to call a PHP file inside a plugin from cron.

For how to track down why WP-Cron isn't running, see "Causes and fixes when WP-Cron doesn't run". For WP-CLI's cron commands, see "How to check and run cron events with WP-CLI".

Summary

• WP-Cron runs when the site gets a visit, so on quiet sites scheduled posts and other tasks run late.
• Add define( 'DISABLE_WP_CRON', true ); to wp-config.php to stop it from starting on page views.
• Run it from server cron every 5 minutes or so using WP-CLI (wp cron event run --due-now), PHP or curl. On a VPS, run it as the same user as the web server.
• Use wp cron event list to check that no overdue tasks are left.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)