The crontab command in Linux
cron runs commands on a schedule; crontab edits your personal table of them. Each line is five time fields — minute, hour, day-of-month, month, day-of-week — followed by the command. Backups, report generation, cleanup jobs and certificate renewals across the world's servers are almost all cron lines.
How crontab works
The cron daemon wakes once a minute, compares every loaded table against the current time, and spawns matching jobs. Your crontab -e edits a per-user file kept in /var/spool/cron (never edited directly — the command validates and signals the daemon), alongside the system-wide /etc/crontab and /etc/cron.d.
Jobs are born into an almost empty world: minimal PATH, no interactive shell configuration, $HOME as working directory, no terminal. That sparse environment — not cron's scheduling — causes virtually every "works by hand, fails from cron" report; absolute paths and explicit output capture are the vaccine. One more design fact: classic cron never catches up missed runs (a 3am job on a machine asleep at 3am simply doesn't happen); anacron and systemd timers exist precisely to fill that gap.
Syntax
crontab [-e | -l | -r] # line: m h dom mon dow commandCommon options
| Option | What it does |
|---|---|
-e | Edit your crontab (creates it if missing). |
-l | List it. |
* | Any value. |
*/15 | Every 15 units (e.g. every 15 minutes in the first field). |
1-5 | Ranges: Monday to Friday in the day-of-week field. |
@daily @reboot | Shortcuts for common schedules. |
How to use crontab: examples
$ 0 3 * * * /home/user/backup.shEvery day at 03:00.
$ */10 * * * * /usr/local/bin/healthcheck.shEvery ten minutes.
$ 0 9 * * 1-5 /scripts/report.sh >> /var/log/report.log 2>&1Weekdays at 09:00, with output captured — always capture output.
$ @reboot /home/user/start-tunnel.shOnce at every boot.
$ crontab -lReview what is scheduled before you assume nothing is.
Real-world use cases for crontab
The self-maintaining server
Three cron lines run most small servers: a nightly rsync backup, a weekly find -mtime cleanup of old artifacts, a certbot renew twice daily. Set once, verify with crontab -l, and the machine tends itself.
Scheduled reporting
0 8 * * 1 report.sh 2>&1 | tee -a /var/log/report.log mails the week's numbers before Monday coffee. Every recurring business ritual — exports, syncs, digests — compiles to one crontab line.
Pro tips and common mistakes
- Absolute paths for everything — commands and files. Cron's PATH is not your PATH, and this causes 90% of failures.
- Every job ends with >> /var/log/job.log 2>&1; a job that fails silently costs you exactly when you can least afford it.
- Test the command in an env -i sh first — surviving an empty environment predicts surviving cron.
Frequently asked questions about crontab
My script works manually but not from cron — why?
Cron's environment is minimal: different PATH, no home-shell config, working directory is $HOME. Use absolute paths (commands and files), and capture output (>> log 2>&1) so failures leave evidence.
How do I write "every Monday at 8"?
0 8 * * 1 — minute 0, hour 8, any day-of-month, any month, weekday 1. Sites like crontab.guru translate; fluency comes fast.
Where does cron output go?
By default it tries to mail it (usually nowhere useful). Redirect explicitly in each line; silence plus a log file beats mysterious emails.
Related commands
Change file permissions with numeric (755, 644) and symbolic (u+x) modes — clearly explained.
echoPrint text and variables, and write or append to files with > and >>.
journalctlQuery the system journal: by service, time window, priority — and follow live.