The best ways to manage WordPress cron: wp-cron

wp-cron is WordPress’ version of a cron job and a cron job is a task that is run on a schedule, whether just once at a particular date and time or on a recurring basis, like every day at 3pm, or every hour on the 15th minute.

How is wp-cron different from regular cron?

Traditional Linux cron jobs run at precisely the time and date they are configured to run; the same is true in Windows with the Task Scheduler. However in most hosting environments WordPress doesn’t have full system access to be able to add itself to the operating system’s cron jobs, which is necessary for tasks to trigger at exactly their configured date and time.

To work around this, WordPress uses a best-effort (‘as close as we can get’) approach to scheduling tasks. Whenever a visitor views a page on the website (that is not cached such as every admin page, or the WooCommerce cart) WordPress checks to see if it needs to run something in wp-cron and, if so, it proceeds to run through those scheduled tasks in the background and then serves up the actual page that was requested as well.

When can wp-cron fail to run as expected?

The downside of this best-effort approach is that if most of your site’s traffic hits cached pages (which is best for performance), wp-cron will not have an opportunity to run because no dynamic processing is occurring to trigger it. To solve this, you’ll need to set up an actual system cron job in Plesk to trigger wp-cron. We’ll walk you through this process below.

How to create a real cron job for wp-cron using Plesk

If you suspect you’re having problems with a cron task, or if you’d like to improve performance when visitors visit an uncached page, you should decouple normal page views from wp-cron. This will ensure that scheduled tasks won’t interfere with important actions like a customer in the cart, or checking out.

Please note: if you’re hosted with us, the option to access Scheduled Tasks in Plesk is not available with the Helium and Carbon hosting plans. Upgrade to Titanium to gain access to Scheduled Tasks.

Disable default wp-cron mode

To disable automatic triggering of the WordPress cron job, edit the wp-config.php file via FTP, or Plesk File Manager. Look for a line that says “Other Customizations” and add the following just after it on a line of its own:

define('DISABLE_WP_CRON', true);

Set up a Scheduled Task in Plesk

1. Log in to Plesk and choose Websites & Domains > Scheduled Tasks > Add Task.
2. Choose the option to Fetch a URL and enter the URL as: https://yourdomain.com/wp-cron.php
3. Set your schedule to run hourly (on a VPS you may enter a much more frequent schedule, however on shared hosting a very frequent scheduled task will likely be auto-terminated at some point in the near future).

Tip: If you are anticipating some long running tasks from wp-cron (example: you have > 100 WooCommerce products) and you have your own VPS, instead of choosing “Fetch a URL” in the Plesk Scheduled Task, you should change that to run a PHP script and enter the relative path to wp-cron. That usually looks like httpdocs/wp-cron.php.

Source: Plesk Customer Documentation

Troubleshooting & Tips

• If you receive PHP memory limit errors when cron runs, and you’re using the “Fetch a URL” method, you’ll need to increase the PHP Memory Limit using the settings in Plesk. If you’re using the PHP Script method, you will need to increase the memory_limit in your php.ini for all domains.
• If you are using WooCommerce, it also has its own scheduled events queue, but it does rely upon wp-cron to function.
• WooCommerce has an excellent guide to troubleshooting wp-cron (whether you’re using WooCommerce or not) here. We strongly recommend checking it out if you think you’re having trouble with wp-cron.

Reasons not to enable wp-cron on a development or staging site

If you are not using WooCommerce or a subscription based system, it’s probably safe to enable wp-cron on a staging site if you wish. However there are some big issues that can be created if you enable wp-cron on a staging or development copy of your site. Here’s a few of them we’ve encountered:

• Subscription renewals get triggered on cron and clients receive renewal notices that point to the dev site; if they then renew there you have a complete data inconsistency between the live and dev site
• Automations will begin running that you also expect to only occur on live
• Wishlists and backorder notifications can be affected if you change the stock on dev for testing, and cron runs and begins sending notifications to clients that things are back in stock