Skip to content

Scheduled tasks (cron)

WordPress relies on scheduled tasks — publishing scheduled posts, clearing transients, running plugin and backup jobs, and more. On SuperSpace, WordPress's scheduled tasks are already taken care of for you, and you can also add your own scheduled commands if you need them.

WordPress cron is handled for you

By default, WordPress runs its scheduler (WP-Cron) by triggering wp-cron.php on visitor page loads. That's unreliable: on a low-traffic site, scheduled tasks fire late or not at all, and on a busy site the extra work runs on every request.

SuperSpace avoids both problems. It disables the page-load trigger and instead runs wp-cron.php from a real system cron on a fixed schedule (a couple of times an hour). The result is that your scheduled posts and plugin jobs run on time regardless of traffic — with nothing for you to set up.

Multi-container sites

If your site runs across more than one container, SuperSpace makes sure the WordPress cron runs in just one place, so scheduled jobs don't fire twice.

Adding your own scheduled tasks

If you need to run your own commands on a schedule — a maintenance script, a WP-CLI command, a call to an external service — add them to the crontab file at the root of your site's volume:

/home/sftpuser/apps/{{ container name }}/wordpress/crontab

Reach it with any file-access method — SFTP, SSH, the File Manager, or Cloud Shell. See Accessing your files for how to connect.

  1. Open (or create) the crontab file in the volume root.

  2. Add one line per job, in system-cron format: the five schedule fields, then the user to run as (use www-data), then the command. For reference, SuperSpace's own WordPress-cron line looks like this:

17,47 * * * * www-data /usr/bin/curl http://localhost/wp-cron.php?doing_wp_cron

A custom job to clear expired transients every night at 3:15 AM:

15 3 * * * www-data wp --path=/var/www/html/wordpress transient delete --expired
  1. Restart the site. In the dashboard, open the site's Settings and use the Restart action. SuperSpace reads the crontab file when the site boots, so new or changed jobs apply after a restart.

Two things that trip people up

  • The user field is required. Each line needs a user (www-data) between the schedule and the command — leaving it out is the most common reason a job silently doesn't run.
  • Commands run inside the site container. Paths are relative to that container, not your SFTP login — for example, WordPress lives at /var/www/html/wordpress there, so pass that to wp --path=…. Cron also runs with a minimal environment, so use full paths to binaries if a command isn't found (SuperSpace's own entry calls /usr/bin/curl).

Leave the WordPress-cron entry in place

Your jobs are added alongside SuperSpace's WordPress cron — you may notice SuperSpace add its own wp-cron line to this file. Leave it there; removing it would stop WordPress's scheduled tasks from running.

Removing a custom job

Delete the line from the crontab file and restart the site. Removing your own lines won't affect the built-in WordPress cron.