Skip to content

Server wp-cron

WordPress has scheduled tasks: publishing a post you planned, sending e-mails, checking for updates, cleaning up. It calls this wp-cron. By default, WordPress runs those tasks during a visitor's page load. Whoever happens to arrive at the right moment waits for the work to finish before the page renders.

That creates two problems at once. Visitors pay for work that has nothing to do with the page they asked for. And on a quiet site nobody arrives, so the tasks simply don't run: your planned post stays unpublished, your e-mails stay unsent.

Wondering how to move that work off your visitors' page loads? This article explains what server wp-cron does and how to turn it on.

Where to find the page

Directly

  1. Navigate to 'Advanced' > 'Virtual Hosts'.
  2. Select the virtual host.
  3. Navigate to 'Server wp-cron'.

Via the project

  1. Navigate to 'Projects'.
  2. Select the project.
  3. Navigate to 'Advanced' on the environment you want.
  4. Under 'Virtual Host', click 'Manage'.
  5. Navigate to 'Server wp-cron'.

What the page shows

Cyberfusion checks both halves of the setup and shows one of four states:

State Meaning
'Active' A cron runs the scheduled tasks every minute, and WordPress no longer runs them on page loads. This is what you want.
'Not active' WordPress runs the tasks during page loads. Those page loads are slower, and when nobody visits, the tasks don't run.
'Runs twice' There is a cron, but WordPress still runs the tasks on page loads too. Visitors wait for work that is already done.
'Nothing runs the scheduled tasks' WordPress has been told not to run them, and no cron does it instead. Planned posts are not published and e-mails are not sent.

In any state other than 'Active', the 'Configure Server wp-cron' button sets up whichever half is missing.

The problem it fixes

WordPress has scheduled tasks — publishing a planned post, sending e-mails, checking for updates, cleaning up. It calls this wp-cron.

By default WordPress runs those tasks during a visitor's page load. Whoever arrives at the right moment waits for the work to finish before the page renders.

That causes two problems:

  • Visitors wait for work that has nothing to do with the page they asked for.
  • On a quiet site nobody arrives, so the tasks never run. Your planned post stays unpublished and your e-mails stay unsent.

What 'Configure Server wp-cron' does

Two things, which only work as a pair:

  1. Sets DISABLE_WP_CRON to true in the site's WordPress configuration, so WordPress stops running tasks on page loads.
  2. Creates a cron named wp-cron for the site, running wp cron event run --due-now against its document root every minute.

The cron gets a random delay of up to 10 seconds, so sites don't all fire on the same second, and locking is on, so a run that takes longer than a minute is never started twice at once. It times out after 10 minutes. You can view and adjust it like any other cron; see All about crons.

If the UNIX user already has a wp-cron cron

The cron is identified by its name. Core leaves an existing one alone and only turns off wp-cron in WordPress.

Running several WordPress sites under one account? Check that the existing cron points at the site you mean.

Sites that already have it

WordPress sites created through Core, including the ones installed automatically with a project environment, get server wp-cron from the start. Their page shows 'Active' and there is nothing to configure.