A brief history of cron

Almost every scheduled job on a Unix-like system today is descended from a program written at Bell Labs in the 1970s. The implementations have been replaced several times over. The five-column table you edit with crontab -e has barely changed.

The name

“Cron” comes from chronos, the Greek word for time, the same root as chronology and chronometer. The program is a clock-work daemon: it wakes up, checks what is due, runs it, and goes back to sleep.

Version 7 Unix, 1975–1979

The first cron shipped with early Research Unix at Bell Labs and was standardised in Version 7 Unix (1979). It was about as simple as a scheduler can be. A single daemon woke once a minute, read one system-wide table (/usr/lib/crontab), and ran any line whose time matched. There were no per-user crontabs, no crontab command, and no spooling. If you wanted a job scheduled, you edited the file as root.

Waking every minute to re-read a file is wasteful, but on a shared PDP-11 with a handful of scheduled tasks it did not matter. The design priority was that it be small, obvious, and hard to break.

System V: per-user crontabs

As Unix spread through universities and companies in the early 1980s, one table owned by root stopped being enough. The System V branch introduced the pieces still in use now:

• a crontab command to install, list, and remove your own table, so ordinary users could schedule jobs without root;
• per-user files under a spool directory (/var/spool/cron/crontabs on most systems today);
• /etc/cron.allow and /etc/cron.deny to control who may use it.

The daemon also got smarter about sleeping: instead of a fixed one-minute tick, it could compute the time until the next scheduled job and sleep for exactly that long.

Vixie cron, 1987

In 1987 Paul Vixie released a fresh implementation that combined the System V feature set with a much richer schedule format. “Vixie cron” became the default on BSD and then on early Linux distributions, and its schedule syntax is what people now mean by “cron syntax.” It is the format the modern crontab(5) man page still documents.

Vixie cron is where the modern crontab line comes from:

• ranges (1-5), lists (1,15,30), and steps (*/10) in any field;
• three-letter names for months and weekdays (JAN, MON);
• the @reboot, @daily, @hourly and related shorthand macros;
• environment variables set inside the crontab itself: PATH, SHELL, and MAILTO, which controls where a job's output is emailed.

MAILTO="[email protected]"
PATH=/usr/local/bin:/usr/bin:/bin

# min hour dom mon dow   command
*/15 9-17 * * 1-5   /usr/local/bin/sync-inventory
0    2    1 * *     /usr/local/bin/rotate-archives

Vixie cron also established a habit that still catches people out: cron jobs run in a deliberately minimal environment. A short PATH, no shell profile, and a working directory of the user's home. A command that works in your interactive shell can fail under cron for no reason other than a missing variable.

The schedule format was good enough in 1987 that nobody has had a strong reason to replace it. Every scheduler since has either adopted it or deliberately echoed it.

The forks: cronie, dcron, fcron, anacron

Vixie cron was donated to ISC and then forked repeatedly to fit different needs.

• cronie is Red Hat's fork, now the default on Fedora, RHEL, and their derivatives. It adds PAM and SELinux integration, the /etc/cron.d drop-in directory, and run-parts handling for /etc/cron.hourly, cron.daily, and so on.
• anacron is built for machines that are not on around the clock. Cron assumes the computer is always running; if it is asleep at 3 a.m. the daily job is simply missed. Anacron records when each job last ran and catches up after boot. Most desktop Linux installs pair the two.
• dcron (Dillon's cron) and fcron are smaller or more featureful alternatives used on distributions like older Arch and Gentoo setups.

systemd timers, 2010s

As systemd took over init duties on most Linux distributions, it brought its own scheduler: a .timer unit paired with a .service unit. Timers use a different calendar syntax (OnCalendar=) rather than the five columns, and add things cron never had:

• Persistent=true gives anacron-style catch-up for missed runs, built in;
• RandomizedDelaySpec= adds jitter, so a fleet of machines does not all hit a server at exactly 03:00;
• full journald logging, resource limits, and dependency ordering, because the job is a normal systemd service.

Many distributions now ship their routine maintenance as timers. Plenty of people still install a cron daemon anyway, because a crontab line is faster to write than two unit files.

Cron in the cloud and the cluster

The format kept travelling. Kubernetes added CronJob (stable in 2021), which runs a container on a schedule written in, of course, standard cron syntax, later gaining a timeZone field. AWS EventBridge Scheduler, Google Cloud Scheduler, and GitHub Actions' schedule: trigger all accept cron expressions, though several use a six-field variant with a seconds or year column and their own rules about the day-of-week field. “Cron syntax” is a family of dialects now, not one specification.

What hasn't been solved

Fifty years in, the thing cron still does not do is tell you when a job stopped. It has no memory of whether last night's run succeeded, ran late, or ran at all. Vixie cron will email you a command's output, but only if the host has a working mail transfer agent, which cloud instances usually do not. systemd timers log to the journal, which nobody is watching at 4 a.m.

That gap is why external monitoring exists: the job reports in on a schedule, and something off the box notices when the report does not arrive. It is the one piece the 1975 design left for someone else, and it is still worth adding to anything you actually depend on.

If you want to see the schedule side rather than the monitoring side, the cron expression tester turns any of these expressions into its next run times.