Schedule work with crontab

The five fields

A user crontab has five time fields followed by a command:

minute hour day-of-month month day-of-week command
0      2    *            *     *           /home/fresher/backup.sh

This example runs daily at 02:00. 30 8 * * * means 08:30 every day; 0 14 * * 6 means 14:00 Saturday. Minute comes before hour, so swapping them creates a different schedule. Day-of-week counts from 0 (Sunday) to 6 (Saturday), and 7 also means Sunday.

flowchart LR
  E["crontab -e<br/>*/15 * * * *"] --> CR["cron daemon<br/>checks every minute"]
  CR --> SH["/bin/sh<br/>minimal PATH"]
  SH --> JOB["/opt/backup.sh<br/>absolute paths"]
  JOB --> LOG["Log file<br/>stdout and stderr kept"]
  %% step E: Each line has five time fields (minute hour day month weekday) and a command.
  %% step CR: The cron daemon wakes every minute and runs lines whose fields match.
  %% step SH: Jobs run in a minimal shell without your interactive PATH or variables.
  %% step JOB: Use absolute paths in the command and inside the script.
  %% step LOG: Redirect stdout and stderr to a log so failures are visible.

Ranges, lists, and steps

An online cron expression checker helps you confirm a schedule before saving it.

Where jobs are defined

crontab -l lists and crontab -e edits the current user's crontab. The system crontab /etc/crontab and files in /etc/cron.d/ add a sixth field, the user to run as, between the time and the command. Scripts dropped into /etc/cron.daily/ or /etc/cron.weekly/ run on those schedules without writing any time fields.

The cron environment

Cron runs with a small environment: PATH may differ from an interactive shell, the working directory is not guaranteed, and output may be mailed or discarded depending on configuration. Use absolute paths for important scripts and executables and redirect logs deliberately:

0 2 * * * /home/fresher/backup.sh >> /home/fresher/backup.log 2>&1

A script must exist and be executable, or be invoked through an interpreter such as /bin/bash /home/fresher/backup.sh. Cron cannot repair incorrect permissions. Variables such as PATH= or MAILTO= at the top of a crontab apply to the jobs below them.

Debugging and alternatives

To check that a job ran, look at the cron log: grep CRON /var/log/syslog on Ubuntu, or journalctl -u cron. If a long job might still be running when the next one starts, wrap it with flock so only one copy runs. On systemd hosts, timers are an alternative that log through the journal and can catch up on runs missed while the machine was off.