Cron and WP-CLI

WordPress has no clock of its own. WP-Cron, which runs the warmer on its schedule, is only checked when somebody loads a page. A shop with little traffic at night is exactly the shop whose scheduled jobs never fire, and night is when the warmer has the most room to work.

If the dashboard says Warming has stopped or Nothing has run yet, or the number of URLs never warmed does not go down on its own, give the warmer a real cron entry.

The How it works tab shows the three routes below with your site’s own paths already filled in, and a live read of your cron setup.

Pick a route

They are in order of how well they hold up on shared hosting, best first.

1. Secret cron URL

Works on any hosting with a cron panel. It needs no shell and no WP-CLI. It runs the warmer and nothing else, so it can neither hold up nor be held up by other plugins’ scheduled jobs.

1. In wp-admin, open Cache Warmer > Settings, panel Running the worker, and copy the Cron command. It looks like this:

   wget -q -O - "https://example.com/?brl_scw_run=YOUR_KEY" >/dev/null 2>&1

2. In cPanel, open Cron Jobs under Advanced. On Plesk it is Scheduled Tasks; other panels call it Cron.

3. Set the schedule to every five minutes: */5 in the minute box, * in the other four.

4. Paste the whole line into the Command box.

Caution

Paste the whole line, not only the address. A cron panel runs what you give it as a shell command, so an address on its own fails with “No such file or directory”.

If the server has no wget, use curl -s "URL" >/dev/null 2>&1 with the same address.

For an external cron service such as cron-job.org, or a monitor that pings a URL, use The address on its own instead.

2. WP-CLI

Runs outside the web request, so the PHP time limit that cuts a browser request short does not apply. Needs WP-CLI on the server and SSH access.

1. Over SSH, run which wp and note the full path. It is usually /usr/local/bin/wp.

2. Add a cron entry that goes to your WordPress folder and runs one batch, every five minutes:

   */5 * * * * cd /path/to/wordpress && /usr/local/bin/wp brl-scw run >/dev/null 2>&1

Use the full path to wp. Cron does not read your shell profile, so a bare wp that works over SSH often fails from cron. You can name the PHP binary as well, to pin the PHP version to the one your site runs on.

While testing, send the output to a file instead of /dev/null, for example >> ~/warmer-cron.log 2>&1, so a missing binary shows up instead of failing silently.

3. Real WordPress cron

Drives every scheduled job on the site, not only the warmer. Right for a site whose cron is generally behind.

1. Add this to wp-config.php, above the line that says “That is all, stop editing”:

   define( 'DISABLE_WP_CRON', true );

2. Add a cron entry on the server that calls wp-cron.php every five minutes:

   */5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Caution

A cron queue that has been starved for a while holds old jobs from other plugins, sometimes ones that email customers. Run wp cron event list first and read what is waiting.

Add route 1 alongside this one anyway. The warmer is a heavy job, and keeping it out of the shared queue stops it holding everything else up.

How to tell it worked

Wait for two runs, then check Last run on the dashboard or the How it works tab, or open the Log tab. The number of URLs never warmed should go down on its own.

The secret cron URL

The address runs one batch and nothing else. It works only with the random key generated on your site; a wrong key gets a 403. A cron entry cannot send a login or a nonce, so the key is the credential. Treat the address like a password.

• It warms one batch whether or not the Worker switch is on. Leave the switch on anyway: the worker interval still decides which URLs count as due.
• The response is a short line of plain text, such as ok: 15 URLs, 30 requests, 4.2s.
• Adding &task=rebuild to the address re-reads the sitemap instead of warming.

To replace the key, click Generate a new key under Settings > Running the worker. The old address stops working immediately, so update your cron entry straight after.

WP-CLI commands

Everything the dashboard buttons do, without a browser waiting on it.

Command	What it does
wp brl-scw run	Runs one batch, exactly as cron would. Safe in a cron entry. Does nothing while the Worker switch is off.
wp brl-scw rebuild	Rebuilds the queue from the sitemap, or from published content when there is none.
wp brl-scw warm <url>	Warms one URL now and prints the HTTP code and what the desktop and mobile buckets answered.
wp brl-scw status	Prints the queue size, URLs never warmed, URLs warmed in 24 hours, the cold share, the cache header and the time for a full cycle.
wp brl-scw reset	Clears every warm result, so the whole queue is due again. Does not purge the cache.

Before version 1.2.3 the command was wp brl-warmer. The old name still works, so existing cron entries keep running.

DISABLE_WP_CRON is on

That is not a problem by itself; it is the better setup, as long as something outside WordPress really calls wp-cron.php. If Next run on the dashboard is not overdue, your server cron is alive.

wp cron test always fails when the constant is set. It only tests the visitor-driven path, which you turned off on purpose.

“Run one batch now” hangs the admin page

Your server is handling one PHP request at a time. Run one batch now warms inside the admin request, and the warm requests queue behind the very request that sent them, so neither can finish. It shows up on local dev servers and on a php-fpm pool sized to a single worker. Normal hosting does not do this.

Let the background worker or a cron entry do the warming instead, or raise the number of PHP workers.