Skip to content

Cron jobs

How Avaloi runs WordPress cron from the server, how to schedule your own WP-CLI commands, pause or delete them, and read what each run did.

Avaloi runs cron on the server, not on page loads. Open your site, then Tools, then Cron, to see WordPress's own cron, add jobs of your own, pause them, and read what happened on the last run.

How it works

  • WordPress cron runs from the server. Avaloi turns WP-Cron off in wp-config.php on every environment, so visiting a page never starts it. On live, the server runs wp cron event run --due-now every 15 minutes. Each site has its own minute within that window and a short random delay, so a server full of sites does not start every site at the same second. Scheduled posts, plugin tasks, and WooCommerce actions can start up to 15 minutes late.
  • Your jobs run the same way. Each job is one WP-CLI command that runs as your site's own user, never as root. It runs from the site root. A run that is still going when the next one is due makes the next one skip, so runs never pile up. A run that takes more than an hour is stopped.
  • Everything is logged. Every run adds a line to the cron.log on the Logs tab: when it finished, how long it took, its exit code, and the end of its output. A failed run is marked as an error.

Open it

  1. Open a site and pick the environment in the top bar.
  2. Choose Tools, then Cron.

The WordPress cron card comes first. Below it, the list shows each of your jobs with its schedule, its last run, and its status.

Add a cron job

  1. Choose Add cron job.
  2. Pick when it runs. Use the schedule builder for common times, or switch to the cron expression field for anything else. Times use UTC.
  3. Enter one WP-CLI command, with or without the wp prefix. For example, transient delete --expired or option get blogname.
  4. Save.

A job can run at most once every 5 minutes, and may start up to 45 seconds after its time. Avaloi refuses a faster schedule and tells you why.

Which commands a job can run

A job can run any command the WP-CLI tool allows, and nothing else. No pipes, redirects, &&, ;, backticks, or $( ). No php scripts, and no wp eval or wp eval-file. Avaloi checks the command when you save it and again on the server, and puts each part of it in quotes, so nothing you type is read by a shell. To run your own PHP on a schedule, put the code in a plugin and schedule it as a WordPress event with wp cron event schedule; the 15 minute run starts it.

On live in Git mode, code is read-only. A job that would install, update, delete, or activate a plugin or theme is refused there, the same as in the WP-CLI tool. Do those changes on staging and push them. A cron job never writes code on live.

WordPress cron on your environments

Environment WordPress cron
Live On. The server runs it every 15 minutes.
Staging and multidev Off.

Staging and multidev start with a copy of live data. WordPress cron there could send scheduled mail or take subscription renewals a second time, so Avaloi leaves it off. Your cron jobs on live are never copied to them either. To turn WordPress cron on for an environment, add a job there that runs cron event run --due-now.

To run WordPress's events on another schedule on any environment, add a job whose command is cron event run --due-now and pick its schedule, for example every 5 minutes. Your job then replaces the built-in run. Pause it and WordPress's events stop; delete it and the built-in run comes back (on live).

Cron jobs belong to one environment. They stay in place when you promote staging to live, launch live, clone, or restart PHP, and they come back after a server restart.

What the status means

Status Meaning
Healthy The last run exited with code 0, and no run is overdue.
Last run failed The last run exited with a code other than 0. The row shows the last error line of its output.
Missed a run A run was due more than 10 minutes ago and did not happen.
Not allowed The command is not an allowed WP-CLI command, so it never runs. Edit it to a valid command.
Paused The job is off.
Waiting for first run The job has not run yet.

The WordPress cron card shows Running, Failing, Not running, or Off. Not running means the server stopped running it. Avaloi repairs that on its own and tells support if the repair does not work.

A failed run, a missed run, and a stalled WordPress cron also add a notice to the bell, once per problem. The notice has the last error line. You can turn these off under the Site status and health notifications.

Pause and resume

Pause a job from its switch or its menu. A paused job keeps its schedule and command but does not run. Flip the switch again to resume it.

Read the last run

Open a row to see the last run: the exit code, the output, and when Avaloi removes that output. Avaloi keeps the output for 7 days. The cron.log on the Logs tab keeps the summary of every run for longer.

Delete a cron job

Delete from the job's menu. Delete asks you to type the job's description to confirm.

Limits

  • Fastest schedule: once every 5 minutes. Up to 45 seconds of delay.
  • Up to 100 jobs per environment.
  • A run stops after 1 hour. The built-in WordPress run stops after 10 minutes.
  • Output of the last run is kept 7 days.

Quick answers

Avaloi refused my schedule. The schedule runs more often than every 5 minutes. Choose a slower one. Through the API, the request returns 422 with an explanation.

Avaloi refused my command. Only allowed WP-CLI commands run. The message says what is wrong: shell syntax, a command that is not on the list, or a code change on live in Git mode.

Does a cron job run on staging too? Cron jobs belong to one environment. Pick the environment in the top bar before you add one. Jobs on live are not copied to staging, and WordPress cron is off on staging unless you add a job for it.

Where is the output of a run from last month? Avaloi keeps output for 7 days. Older output is gone from the Cron tab, and the summary line stays in the cron log until the log rolls over.

API

  • GET /v1/environments/{id}/cron
  • POST /v1/environments/{id}/cron
  • PATCH /v1/environments/{id}/cron/{cron_id}
  • DELETE /v1/environments/{id}/cron/{cron_id}
  • GET /v1/environments/{id}/logs/{file}, with file set to cron

Still stuck?

Email [email protected] with your site name and what you tried, or send us a message.