Crontab

A crontab (short for cron table) is the configuration file that tells the cron daemon which commands to run and when to run them. Each line in a crontab pairs a cron expression with a shell command. The cron daemon reads these files every minute and executes any commands whose schedule matches the current time.

Crontab vs the cron daemon

The cron daemon is the background process that does the actual scheduling and execution. The crontab is the file it reads to know what to run. Think of the cron daemon as the engine and the crontab as the instruction sheet. You never interact with the daemon directly — you edit the crontab, and the daemon picks up the changes automatically.

Managing your crontab

The crontab command is also the CLI tool used to manage your cron schedule file. Three flags cover most use cases:

Command	Description
crontab -e	Open your crontab in the default editor. Changes take effect immediately on save.
crontab -l	Print your current crontab entries to stdout.
crontab -r	Delete your entire crontab. There is no confirmation prompt — be careful.

On multi-user systems, administrators can manage another user's crontab with crontab -u username -e.

Crontab file format

Each line in a crontab follows the same structure: five time fields followed by the command to execute.

Field	Allowed values
Minute	0 – 59
Hour	0 – 23
Day of month	1 – 31
Month	1 – 12
Day of week	0 – 6 (Sunday = 0)

For example, 30 2 * * 1 /usr/local/bin/backup.sh runs backup.sh every Monday at 2:30 AM. For a detailed breakdown of the syntax, including wildcards, ranges, and step values, see the cron expression reference. You can also build expressions interactively with our cron expression generator.

Environment variables in crontab

Crontab entries run in a minimal shell environment — not the interactive shell you're used to. This catches people off guard. You can set environment variables at the top of the crontab file, and they apply to all entries below them:

• PATH=/usr/local/bin:/usr/bin:/bin — set the PATH explicitly so your commands are found
• SHELL=/bin/bash — override the default shell (usually /bin/sh)
• [email protected] — send command output to this email address
• MAILTO="" — suppress all email output

If a command works in your terminal but fails silently in cron, the most likely culprit is a missing PATH entry. Always use absolute paths for commands or set PATH at the top of your crontab.

Per-user vs system crontab

Per-user crontabs are stored in /var/spool/cron/ (Linux) or /var/at/tabs/ (macOS). Each user manages their own file via crontab -e. Commands run as the owning user.

The system crontab at /etc/crontab has an extra field between the time fields and the command: the username to run the command as. Files in /etc/cron.d/ follow the same format. These are managed by root and are typically used for system maintenance tasks like log rotation and package updates.

Feature	Per-user crontab	System crontab
Location	/var/spool/cron/	/etc/crontab, /etc/cron.d/
Managed by	crontab -e	Direct file editing (root)
User field	No (runs as owner)	Yes (specify which user)
Typical use	Application-level tasks	OS maintenance

Common crontab gotchas

• PATH is minimal — cron doesn't load your .bashrc or .profile. Commands that work in your terminal may fail in cron because the binary isn't on the cron PATH.
• No interactive shell — cron jobs can't prompt for input. Commands that expect user interaction will hang or fail silently.
• Output goes to email — by default, cron mails stdout and stderr to the crontab owner. If mail isn't configured, output is lost. Redirect output explicitly: command >> /var/log/myjob.log 2>&1.
• crontab -r is destructive — it deletes your entire crontab with no confirmation. One wrong keystroke (r instead of e) and everything is gone. Back up your crontab regularly with crontab -l > crontab.bak.
• No overlap protection — if a job takes longer than the interval between runs, cron starts a second instance. Use lock files or flock to prevent concurrent execution.
• Timezone mismatch — cron uses the system timezone. If your server is in UTC and you think in local time, your jobs will run at unexpected hours.

FAQ

What is the difference between cron and crontab?

Cron (the cron daemon) is the background process that executes scheduled commands. Crontab is the file that contains those scheduled commands — the schedule itself. You edit the crontab; the cron daemon reads it and runs the commands.

Where is the crontab file located?

Per-user crontabs are stored in /var/spool/cron/crontabs/ on most Linux distributions and /var/at/tabs/ on macOS. You shouldn't edit these files directly — use crontab -e instead, which validates the syntax before saving. The system crontab is at /etc/crontab.

How do I edit my crontab?

Run crontab -e in your terminal. This opens the crontab in your default editor (set via the EDITOR or VISUAL environment variable). Add one entry per line in the format: cron expression followed by the command. Save and exit — changes take effect immediately.

The crontab defines schedules using cron expressions and is read by the cron daemon every minute. For recurring work that needs retries, alerting, and execution history — features crontab lacks — teams move to a dedicated job scheduler. Check out common cron expression examples for patterns you can paste directly into your crontab.