How to use crontab on Linux, step by step

To use crontab, run crontab -e, add one line per job in the form minute hour day-of-month month day-of-week command, then save and exit. Cron installs the file as soon as the editor closes, and the job runs on that schedule from then on.

That is the short answer. Below are the exact steps on a Linux machine, how to confirm the schedule means what you think, and how to fix the usual problems.

Step 1: open your crontab

crontab -e

This opens your personal crontab in the editor named by the VISUAL or EDITOR environment variable. If you have never used it, the file may be empty. Each user has a separate crontab, and sudo crontab -e edits root's.

Step 2: write the schedule

Every job is one line. The first five values set the time, and everything after them is the command.

15 4 * * * /home/ana/bin/backup.sh

So this backup runs at 04:15 every day. Use * for "every", commas for lists (1,15), hyphens for ranges (1-5) and a slash for steps (*/10).

Step 3: check the schedule before you save

Cron will accept a line that is valid but wrong, such as a job you meant for Mondays that runs on the first of every month. Before you save, copy the five time fields into the free AyeTab Cron Parser. For 15 4 * * * it replies "At 04:15 AM" and shows the next run times in UTC. If the sentence is not what you meant, fix the line now.

The parser works inside your browser, with no account and nothing uploaded, so it is safe to use on schedules copied from work servers. It is the same tool that comes with the AyeTab Chrome extension, which puts a set of developer tools on your new tab page.

Step 4: save, then confirm it is installed

Save and close the editor. You should see a message that the new crontab is being installed. To confirm, list it:

crontab -l

Other useful flags from the crontab manual: -r removes your crontab (add -i to be asked first), -u name works on another user's crontab when you are root, and on cronie systems -T file tests a file's syntax without installing it.

Fixing the common problems

"no crontab for user". You have not created one yet. Run crontab -e and save a line.

The job runs by hand but not from cron. Cron starts with a minimal environment, so PATH is short and your shell profile is not loaded. Use full paths to every program, or set PATH= at the top of the crontab.

No output, no idea what happened. Redirect output to a log: ... backup.sh >> /home/ana/backup.log 2>&1.

Wrong hour. Cron follows the server's clock, which is often UTC. Check with date on the server, and compare it with the UTC run times the AyeTab parser shows.

Edited the file directly and nothing changed. Always go through crontab -e so cron picks up the change.

A worked example

Say you want a cleanup script to run at 23:30 on weekdays and write a log. The line is:

30 23 * * 1-5 /home/ana/bin/cleanup.sh >> /home/ana/cleanup.log 2>&1

Paste 30 23 * * 1-5 into the parser and you should read a sentence saying 11:30 PM, Monday through Friday. Save the crontab, run crontab -l to see the line in place, and check the log the next morning. If the log file was never created, the job did not run, and the PATH and clock checks above are where to look first.

When to use something else

For one-off tasks, at is simpler than cron. For jobs that must alert someone when they fail, pair cron with a monitoring service; Cronitor, from the team behind crontab.guru, is one option. For reading and checking the schedule itself, AyeTab is the quick, private first stop.