Teach the system to run your jobs while you sleep.
You could ssh in at 3am to run your backup by hand — or you could teach cron to do it forever. One five-field line is the difference between babysitting servers and letting them run themselves.
crontab is the control panel for cron, the daemon that runs commands on a schedule. Each user owns a crontab file: a list of lines, one per job, each with five time fields (minute, hour, day-of-month, month, day-of-week) followed by the command to run. You edit it with `crontab -e`, list it with `crontab -l`, and remove it with `crontab -r`. The daemon checks these files every minute and fires anything that matches. It is how log rotation, backups, certificate renewal, and cleanups keep running without anyone touching them.
Any task that should happen on a schedule — nightly backups, clearing /tmp, renewing a TLS cert, a daily report — is a cron job. The value is reliability: once the line is in, it runs every time, whether or not you remember. The gotcha is that cron does not load your shell profile: it runs with a bare environment (limited PATH, no your aliases, no your exports), which is why jobs that work when you type them fail mysteriously in cron. Understanding that one mismatch saves hours of debugging.
crontab -l
# m h dom mon dow command PATH=/usr/local/bin:/usr/bin:/bin HOME=/home/kmail # Nightly backup at 02:30 30 2 * * * /home/kmail/scripts/backup.sh >> /var/log/backup.log 2>&1
-l lists the current user's crontab. The header line is just a comment reminding you the fields are minute, hour, day-of-month, month, day-of-week.
echo '0 9 * * 1-5 /home/kmail/scripts/daily-report.sh' | crontab -
$ crontab -l | tail -2 0 9 * * 1-5 /home/kmail/scripts/daily-report.sh
`crontab -` installs a crontab from stdin. Here a job runs at 09:00 on weekdays (Mon-Fri). This is the scriptable way to add jobs — safer than typos in an interactive editor.
crontab -e
# opens in your $EDITOR; add a line and save # This job clears the temp dir at 04:00 every Sunday: 0 4 * * 0 /usr/bin/find /tmp/kmail -type f -mtime +2 -delete
-e opens today's crontab in your default editor. After you save, cron validates and reports a syntax error rather than loading a broken schedule: 'new crontab for kmail' means it parsed cleanly.
| Flag | Meaning |
|---|---|
-e | edit the current user's crontab in $EDITOR |
-l | list the current user's crontab to stdout |
-r | remove (delete) the current user's crontab entirely |
-i | interactive — prompt before deleting when used with -r |
file | - | install a crontab from a file, or from stdin with `crontab -` |
-u user | target another user's crontab (root only; e.g. crontab -u www-data -l) |
* | wildcard in a time field matches every value (e.g. `* * * * *` = every minute) |
cron got its name in 1975 from Ken Thompson, who spelled the Greek word for time, χρόνος (khronos), in English letters. Thompson built cron into Version 7 Unix at Bell Labs. The original ran only once per hour — the minute field and more granular scheduling arrived later in the work of others like Robert Brown. Today cron variants (Vixie cron, cronie, cronet) ship on every major distro, and systemd can schedule too, but the crontab format has barely changed in half a century.
The five-field format — minute, hour, day-of-month, month, day-of-week — was designed in the 1970s for line-printers and tape backups, the recurring jobs of the day. It has a famous quirk: if both day-of-month and day-of-week are restricted (not *), the job fires when EITHER matches — a semantic trap that still trips people today. Cron predates every job scheduler since, and its core design lives on in Windows Task Scheduler and systemd timers.