Schedule a cron job to run a command or call a URL

A cron job runs something on a schedule without you. It is how WordPress processes its pending tasks on a real timer, how a report gets generated overnight, and how a webhook gets polled.

Open Advanced, then Cron jobs, and choose Add cron job.

Choosing a cron job type

The form asks which kind first.

Run command takes a shell command. On WordPress the useful one is WP-CLI, which is already installed.

The Cron jobs page. A table headed RUN COMMAND/REQUEST URL and INTERVAL holds one job running wp-cli cron event run with a custom six asterisk schedule. Below the table, an Allow editing of cron from website container toggle is shown switched off, with text warning that common PHP and WordPress malware will self-proliferate using cron jobs, so the setting is off by default.

wp-cli cron event run --due-now --path=public_html

That runs every WordPress event that is due. A site with DISABLE_WP_CRON set relies on exactly this, and the SSH key article covers getting a shell to test it from, and it is the difference between scheduled posts actually publishing and publishing whenever somebody happens to load a page.

Request URL calls an address over HTTP on a schedule instead. It is the option for an application that exposes its own task endpoint, or for keeping a hosting platform's own timer from going quiet.

Intervals

The dropdown offers every minute, every fifteen minutes, every hour, every day, every week and every month, plus Custom for a raw expression.

Five minutes is the common choice for wp-cron on a low traffic site, and fifteen is a reasonable balance. Every minute is rarely worth it, because each run costs a PHP process start whether or not there is work to do.

Custom takes the standard five-field form of minute, hour, day of month, month and day of week. The saved job displays it back, so you can confirm what you entered was understood rather than guessing.

The toggle you should leave alone

Allow editing of cron from website container is off, and should usually stay off. It solves a problem most sites do not have, and it does so by handing cron write access to code served over the web.

It lets processes running under your website, meaning PHP and SSH, edit the crontab using the crontab binary. The panel warns why that is not a default. Common PHP and WordPress malware propagates itself by installing cron jobs, and it can only do that if the code running on the site has permission to write one.

Turn it on only when something you are deliberately running needs it, and turn it back off afterwards. Jobs you add through this panel do not need it, which is the honest way to read the setting. It is not a permission you must grant to use cron, it is a permission you grant so your site's own code can install cron.

When a job does not run

Three things to check, and they fail in this order.

The command has to work from the website's own directory, and it runs with the website's permissions rather than your SSH user's. A command that works when you type it over SSH can still fail here for that reason. The WordPress example carries --path=public_html for exactly this.

The interval is when the schedule fires, not a guarantee about how long the job takes. Two runs can overlap if the first is still going, which matters for anything that writes, and a job that takes longer than its interval will overlap every time.

And check that the job is actually saved before you assume it is scheduled. The list on the same page is the record of what exists.