crontab registers jobs that run on a schedule. Learn how to read the five time fields, the `-l` and `-e` workflow, and how to load a schedule from a file, by running the commands in a real terminal in your browser.
Updated: 2026-09-07
crontab -l # list the current schedule
crontab -e # edit it
crontab -r # remove all of it
cron reads what you registered and runs it when the time comes.
Nothing is scheduled yet.
$ crontab -l
no crontab for user
One line is one job, and the first five fields are the time.
minute hour day month weekday command
| Position | Meaning | Range |
|---|---|---|
| 1st | Minute | 0-59 |
| 2nd | Hour | 0-23 |
| 3rd | Day of month | 1-31 |
| 4th | Month | 1-12 |
| 5th | Day of week | 0-7 (0 and 7 are Sunday) |
* means every one of them.
These five patterns cover most of what people write.
| Pattern | When it runs |
|---|---|
* * * * * | Every minute |
0 * * * * | Every hour, on the hour |
0 3 * * * | Every day at 03:00 |
0 3 * * 1 | Every Monday at 03:00 |
*/5 * * * * | Every five minutes |
Keeping the schedule in a file and loading it is the reliable way.
$ cat backup.cron
# daily backup at 03:00
0 3 * * * /home/user/project/scripts/backup.sh
$ crontab backup.cron
$ crontab -l
# daily backup at 03:00
0 3 * * * /home/user/project/scripts/backup.sh
Registered. Keeping the file means the schedule can live in git and be installed on another server the same way.
Loading a file replaces the whole schedule.
To add to what is there, save it first with crontab -l > current.cron, append, and load that.
crontab -e opens an editor.
$ crontab -e
The template explains the fields in comments; add your line below them and save. Saving installs it.
$ crontab -r
$ crontab -l
no crontab for user
-r removes everything, without asking.
Take a copy first with crontab -l > backup-of-cron.txt.
crontab is for work that should happen while nobody is watching.
| Situation | What to write |
|---|---|
| Nightly backup | 0 3 * * * /home/user/scripts/backup.sh |
| Health check every five minutes | */5 * * * * /usr/local/bin/healthcheck.sh |
| Weekly report | 0 9 * * 1 /home/user/scripts/report.sh |
| Keep the output | 0 3 * * * /home/user/scripts/backup.sh >> /home/user/logs/backup.log 2>&1 |
cron's environment is not your shell's.
.zshrc is not read and PATH is nearly empty.
Write /usr/bin/python3 rather than python3, and /home/user/scripts/backup.sh rather than backup.sh.
Output is mailed, which means it disappears.
Nothing reaches your screen, so failures go unnoticed.
Append >> logfile 2>&1 and keep the evidence.
% cannot be written directly.
cron reads % as a newline.
Something like date +%Y-%m-%d has to be escaped as \%.
When it does not run, check three things.
Is cron running (systemctl status cron), is the script executable (chmod +x), are the paths absolute.
That order finds it nearly every time.
webterm.appthis site
Advanced Terminal Commands
Learn commands for specific situations
learn.webterm.appa separate site

Commands stick when they show up in a real sequence of work, not one at a time. There is a course that builds them up in order.
See the coursesystemctl / journalctl / chmod / date