Support

Scheduling backups in Akeeba Backup requires entering a CRON Expression. The CRON Expression is the standard way to tell servers when and how often to execute scheduled tasks.

The figure below has a handy cheatsheet with the structure, presets, and special characters of CRON Expressions. Everything is explained in text below.

A CRON Expression can be either a preset or consist of exactly five fields separated by one or more spaces.

All preset names start with the at-sign character. The presets available are:

If you are using a preset you MUST NOT provide any other field or text in the CRON Expression edit box.

If you do not wish to use a preset you will have to provide five fields, separated by one more spaces from each other. The fields are always five in number and appear in this order: minute, hour, day of the month, month, weekday. The hour is expressed in 24-hour format (if you're from the US or Canada you may be calling that “military time”). The day of the month, month, and weekday follow the Gregorian calendar which is the calendar used by the vast majority of Western countries.

The acceptable ranges for each field are:

The fields of CRON expressions accept some special characters as well:

Practical examples

What you cannot do with CRON expressions

You cannot have date expressions based on whole weeks. For example there is no way to specify "every second Sunday" or "every third Monday".

Why use CRON expressions?

CRON has been around to schedule tasks in computer systems since the 1970s. Trying to invent something better than a battle tested solution of several decades is not just hubris, it's completely pointless. Yes, we tried it anyway, and predictably failed for the reason succinctly demonstrated in the relevant XKCD comic.

There were several ideas about how the scheduling drafted, tested, and thrown away between 2017 when implementing this feature found its way into our to-do list and 2023 when it was finally implemented. Every one of them had a major issue. The least problematic of them all is, indeed, CRON expressions. Apparently there's a reason they are still in use since the 1970s: they work, they work well, and it's the devil we know (there's a very large number of IT professionals who understand the limitations of CRON expressions and won't fall for them).

We think that the few edge cases not covered by CRON Expressions are a small price to pay over having to develop, test, and train users to use a completely different scheduling system nobody has ever tried before.

In an attempt to preempt what is going to be a frequently asked question, let us tell you why we didn't go with the "obvious" approach of "run this task ever X amount of time" where X is a static quantity. After all, that's what WP-CRON is doing under the hood, right?

It has to do with the the Three Horsemen of The Task Scheduling Apocalypse: Daylight Savings Time (DST), Leap Seconds, and Inadvertent Overlap.

Let's say you want to execute something every 1209600 seconds (that's 2 weeks) starting February 28th at exactly midnight (00:00:00). This task would execute at 1am starting sometime in March, when the DST comes into effect, and go back to executing at Midnight sometime in October when the DST is no longer in effect. To make things even more interesting, the exact dates this will happen depend on the timezone, even for countries which are normally the same amount of time ahead or behind GMT when DST is not in effect.

If a leap second is added at the end of the year, the backup on January 1st would start at 00:00:01 instead of 00:00:00. This is not all that important on the face of it, until you realise that in the best case scenario WP-CRON executes once every 60 seconds, at the top of the minute… or thereabout. This means that some days WP-CRON would execute at exactly 00:00:00 and would consider the backup scheduled to start at 00:00:01 to be "in the future", therefore the backup would start at best at 00:01:00 — one minute late. Some days WP-CRON would execute a couple of seconds after midnight (e.g. because the server load was a bit higher that day, perhaps because the host was installing updates) in which case 00:00:01 is in the past and the backup starts at 00:00:01 or thereabout. In both cases you'd have a server side CRON job executing WP-CRON every single minute, making this discrepancy a completely maddening occurrence. So, yes, even a second off can be important after all.

Finally, as we'll be mentioning further below, WP-CRON is an unreliable scheduler in its default configuration. Since it doesn't run continuously and it has to carry out other tasks except ours it may not execute our backup task for a while. What if it hasn't executed our task for the past 1209598 seconds since its scheduled backup time? Should we start the task or not? If we do we'll definitely end up with two backups running, having started two seconds apart. We "obviously" should not do that. But what is not actually obvious is how long after the scheduled task start we should give up trying to start the task. What we should do for a backup that runs once every two weeks, once a week, once a day, and once an hour is different. What we should do for a backup that runs once a day and takes 10 minutes to another one that also runs once a day but takes 10 hours are very different as well. In the end of the day, how long is a piece of string?

So, no, the "obvious" solution is far from being either obvious or a solution when you have to do with non-trivial, critical tasks like backups.