Schedule and missed backups

Freshet Backup runs on WordPress's own scheduler, WP-Cron. That works without any setup on most sites, and can quietly stop on some. This page is about telling the two apart, and what to do on the second kind.

WP-Cron runs on page visits

WordPress has no clock of its own. WP-Cron is a check that runs when a page is loaded: on each visit, WordPress looks at what is due and starts it. No visit, no check, no backup.

On a site with steady traffic that reaches WordPress, this is fine. It stops being fine when few requests reach PHP:

• a quiet site, where hours or days pass between visits;
• a cached site, where a full-page cache or a CDN answers most visits from a stored copy before WordPress loads;
• a host that blocks requests from the site to itself, which is how WP-Cron starts its work.

On those sites a backup can sit due for days. WP-Cron is also always a little late, by design: a backup due at 03:00 runs at the first visit after 03:00.

The Schedule row under Settings → Freshet Backup shows when the next run is due. When the due time has passed and the backup has not started yet, the row says so: WordPress starts scheduled tasks only when someone visits the site.

Two things that cover for it

The catch-up. When a backup is a whole interval overdue, it is made the next time an administrator opens wp-admin. It runs after the page has loaded, so wp-admin does not wait for it, and at most once per interval, so a backup that keeps failing does not start again on every click. Last run then ends with Started by the catch-up when wp-admin was opened, because WP-Cron had not run it.

The missed-backup notice. If no backup has worked for twice the interval (two days on a daily schedule, two weeks on a weekly one), a notice appears on every wp-admin page and on the screen itself. It names the likely cause:

• WP-Cron looks stopped. The scheduled run is stuck in the past, so nothing has been starting backups. The fix is below.
• The schedule is still running, so the runs themselves are failing. WP-Cron is fine; the backups start and fail. Last run and its error say why: often a download check that refused, or a Dropbox problem.
• On a site that has never made a backup: No backup has been made yet, and the first one was due …, followed by the WP-Cron sentence.

Changing the schedule restarts the count, so a schedule changed a minute ago is not judged against a deadline it has had no time to meet. Pressing Run backup now clears the notice once that backup works.

A real cron job, for quiet or cached sites

For a schedule that does not depend on visitors, have the server run WP-Cron itself. In wp-config.php:

define( 'DISABLE_WP_CRON', true );

and in the server's crontab, every 15 minutes:

*/15 * * * * cd /path/to/wordpress && wp cron event run --due-now --quiet --url=https://www.example.com

Keep the --url. The Dropbox connection only applies on the site's own addresses, and a command without --url names none, so it would not back up. Use the site's own address, as it appears under Settings → General.

Without WP-CLI, this crontab line does the same job:

*/15 * * * * curl -fsS -o /dev/null "https://www.example.com/wp-cron.php?doing_wp_cron"

Do not set DISABLE_WP_CRON without adding the crontab line. Then nothing runs the schedule at all, and only the catch-up on wp-admin visits keeps backups going.

Every 15 minutes is enough for any of the schedules the screen offers; the job only starts what is due.

Checking that the schedule runs

Look at the end of the Last run row under Settings → Freshet Backup:

• Started on schedule. WP-Cron, or your cron job, is running the schedule.
• Started by the catch-up when wp-admin was opened, because WP-Cron had not run it. The schedule is not running, and only your wp-admin visits are keeping backups going. Add the cron job above.
• Started with Run backup now. You pressed the button; this says nothing about the schedule yet.

Next: wp-config constants.