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.app
Advanced Terminal Commands
Learn commands for specific situations
learn.webterm.app

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
crontab is also in the “Schedule jobs” section of the Linux Commands Cheat Sheet.