Felipe Rojas

I begin with the fields in order, because cron mistakes are almost always a field count or an ordering problem rather than a value problem. Minute, hour, day of month, month, day of week. Five fields, and the day-of-month and day-of-week fields combine with an or, which surprises almost everybody. Each field takes three forms: a wildcard, a list, and a range, and a step can be applied to any of them.

A single value is a single value. A range is inclusive at both ends. Names work for months and days and vary between implementations, so I check the specific cron on the system rather than assuming. The shorthand entries are worth knowing.

The recurring ones map onto expressions you could write by hand, and one does not: the restart entry runs a job when the daemon starts, which is not a schedule at all. It has no relation to a time and it fires every time the machine boots, including after an unexpected restart, so a job using it needs to be safe to run more than once. The environment is the second half of the problem. A cron job gets an almost empty environment: a minimal path, no shell profile, and none of the variables exported in an interactive session.

A command that works when typed and fails on a schedule is usually this. Timezone and daylight saving decide whether a job runs twice or not at all on a transition day. On a scheduler that interprets fields in a named zone, a job in the repeated hour runs twice. I also cover permissions, because the percent sign is special in some implementations, and a job with a restrictive umask can produce output nobody else can read.