A Guide to Creating Scheduled Tasks (Cron Jobs) on Linux with Crontab

What Is Crontab and What Is It For?

Crontab (cron table) is a scheduler mechanism used on Linux and Unix-based systems to run a command or script automatically at predefined intervals. The cron daemon that runs continuously in the background (crond on most distributions) checks the user and system crontab files every minute; if a job is due, it runs it. In server administration, crontab is the standard way to carry out repeating work reliably without human intervention.

In practice, crontab is most often needed for the following purposes:

• Taking database and file backups at a specific time every night
• Rotating log files at set intervals (log rotation) and cleaning up old ones
• Running periodic maintenance scripts such as disk cleanup or temporary file removal
• Clearing or rebuilding the cache at regular intervals
• Automating repeating work such as report generation or email notifications
• Triggering periodic maintenance jobs such as SSL certificate renewal checks

The 5 Fields of a Cron Expression

A cron expression consists of 5 fields, in order: minute, hour, day of month, month and day of week; the fields are separated by spaces and their order is fixed. When a job runs is determined by the time pattern these 5 values define together.

What happens if the day of month and the day of week are both restricted?

This is cron's most frequently misunderstood behaviour. If both the "day of month" and the "day of week" field are something other than * at the same time, cron combines these two conditions with OR logic, not AND: the job runs when either condition is met, both do not have to be satisfied. For example, the expression 0 0 1,15 * 1 runs "on days that are the 1st or the 15th of the month or if that day is a Monday" — not "on days that are the 1st or the 15th and are also a Monday". Not knowing this difference leads to jobs firing far more often than expected.

Special Characters: *, , (Comma), - (Hyphen) and / (Slash)

• * (asterisk): means "every value"; it covers all possible values of the field.
• , (comma): defines a list; for example 1,15 means the 1st and 15th days of the month.
• - (hyphen): defines a range; for example 9-17 covers all hours between 9 and 17.
• / (slash): defines a step value; */5 means every 5 units in that field and can be combined with a range such as 10-40/10.

The cron implementation on most Linux distributions also supports shortcut expressions such as @daily, @hourly, @weekly, @monthly and @yearly; these correspond, respectively, to 0 0 * * *, 0 * * * *, 0 0 * * 0, 0 0 1 * * and 0 0 1 1 *.

Cron Expressions by Example

The examples below show how the field and character rules above come together in practice:

crontab -e, crontab -l and System-Wide Jobs

On most Linux servers cron jobs are managed at two levels: user-level crontab files and system-wide configuration.

crontab -e

crontab -l

Alongside user crontabs, system administrators can also add jobs to the /etc/crontab file or to separate files in the /etc/cron.d/ directory. The difference is this: in a user crontab the command comes directly after the 5 time fields, but in /etc/crontab and /etc/cron.d/ files there is an additional field immediately after the time fields specifying which user account the job runs as. Package installations (log rotation or certificate renewal tools, for example) usually register their own scheduled jobs with the system in this way.

Output Redirection, Logging and Environment Variables

The cron daemon runs jobs in a fairly limited environment, independent of the user's interactive session. Files such as .bashrc or .profile are not loaded; that is why a command that works fine in a terminal can fail with a "command not found" error under cron. Cron's default PATH variable usually contains only basic directories such as /usr/bin:/bin.

In addition, cron by default tries to send the standard output (stdout) and error output (stderr) a job produces to the user as email through the local mail system (MTA). Since most servers have no such mail configuration, these messages either never arrive or fill up the local mailbox. Redirecting output to a log file both makes problems visible and prevents unnecessary mail traffic.

Common Mistakes

• Assuming the script will have the environment variables and PATH of the interactive shell; cron runs in a minimal environment.
• Using relative file paths inside the script; a cron job usually does not start from the working directory the user is used to, so file and command paths need to be written as absolute paths.
• Forgetting to redirect output; this both makes errors disappear silently and fills the mailbox with unnecessary emails.
• Thinking 0 and 7 are different days in the day of week field: in standard cron implementations both 0 and 7 mean Sunday (while 1-6 is Monday through Saturday); this confusion leads to off-by-one errors.
• Restricting the day of month and day of week fields at the same time and expecting AND logic between them — ignoring the OR behaviour explained above.
• Not checking, after editing with crontab -e, whether the script being called has execute permission (chmod +x).

Rather than writing the syntax by hand and risking a mistake in the field order, picking the schedule visually and generating a valid cron expression is a safer route. In KEYDAL's cron generator, when you select the frequency (every N minutes, daily, specific days of the week, a specific day of the month and so on) the tool builds the correct 5-field expression automatically and shows the next 5 run times.