Linux command list

crontab command: run a command on a schedule

__ __ _ _____
\ \ / /__| |_|_ _|__ _ __ _ __ ___
\ \ /\ / / _ \ '_ \| |/ _ \ '__| '_ ` _ \
\ V V / __/ |_) | | __/ | | | | | |
\_/\_/ \___|_.__/|_|\___|_| |_| |_| |_
 
A sandbox for trying crontab. Nothing here can touch your real files.
user@webterm:~/project$
 

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

Syntax

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.

Try it first

Nothing is scheduled yet.

$ crontab -l
no crontab for user

How a line is written

One line is one job, and the first five fields are the time.

minute hour day month weekday command
PositionMeaningRange
1stMinute0-59
2ndHour0-23
3rdDay of month1-31
4thMonth1-12
5thDay of week0-7 (0 and 7 are Sunday)

* means every one of them. These five patterns cover most of what people write.

PatternWhen it runs
* * * * *Every minute
0 * * * *Every hour, on the hour
0 3 * * *Every day at 03:00
0 3 * * 1Every Monday at 03:00
*/5 * * * *Every five minutes

Loading from a file

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.

Editing in place

crontab -e opens an editor.

$ crontab -e

The template explains the fields in comments; add your line below them and save. Saving installs it.

Removing 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.

When you actually reach for it

crontab is for work that should happen while nobody is watching.

SituationWhat to write
Nightly backup0 3 * * * /home/user/scripts/backup.sh
Health check every five minutes*/5 * * * * /usr/local/bin/healthcheck.sh
Weekly report0 9 * * 1 /home/user/scripts/report.sh
Keep the output0 3 * * * /home/user/scripts/backup.sh >> /home/user/logs/backup.log 2>&1

Things that trip people up

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.

Practise it hands-on

webterm.appthis site

  • Advanced Terminal Commands

    Learn commands for specific situations

    Try the tutorial

learn.webterm.appa separate site

>_WEBTERM LEARN

WebTerm Learn: from one command to actually using it

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 course

Related commands

systemctl / journalctl / chmod / date

Frequently asked questions

What are the five numbers?
Minute, hour, day of month, month, day of week. `0 3 * * *` is every day at 03:00, and `*/5 * * * *` is every five minutes.
My script works by hand but fails under cron.
cron runs with a different environment and almost no PATH. Write **absolute paths** for both the command and any files it touches.
Where does the output go?
By default it is mailed to the user, which usually means nobody reads it. Redirect it instead: `>> /var/log/backup.log 2>&1`.
Is `crontab -e` different from editing the file directly?
Yes. `crontab -e` checks the syntax before installing it. Editing the stored file by hand can leave a broken schedule in place.
It is registered but nothing happens.
Check three things in order: is cron itself running (`systemctl status cron`), is the script executable (`chmod +x`), and are the paths absolute.