Crontab

Schedule recurring tasks and scripts automatically on Linux and macOS using crontab, the standard Unix job scheduler.

Crontab is the standard Unix job scheduler that runs scripts and commands automatically at specified times or recurring intervals on Linux and macOS.

What Crontab Does and When to Use It

The crontab command manages the cron table — a per-user file that lists scheduled jobs for the cron daemon to execute. Each entry in the cron table defines a time expression (when to run) and a command (what to run). The cron daemon reads these tables and executes the commands at the specified times without manual intervention.

Crontab is the right tool for recurring, time-based automation: nightly database backups, hourly health checks, log cleanup, certificate renewal, and report generation. Any task that needs to run on a fixed schedule without a human starting it is a candidate for a cron job.

Crontab is not the right tool for event-driven automation (use systemd path units or inotify), one-time delayed execution (use the at command), or complex multi-step workflows with dependencies (use a workflow orchestrator). On systems running systemd, systemd timersoffer an alternative to crontab with better logging and dependency management.

How to Install Crontab

Crontab and the cron daemon are preinstalled on most Linux distributions and macOS. Verify the cron service is active:

=== "Ubuntu / Debian"

```bash
systemctl status cron
```

If cron is not installed, install it with:

```bash
sudo apt install cron
sudo systemctl enable cron
sudo systemctl start cron
```

=== "CentOS / RHEL"

```bash
systemctl status crond
```

The cron daemon runs as `crond` on CentOS and RHEL.

=== "macOS"

Crontab is preinstalled on macOS. The underlying scheduler is `launchd`, but the crontab interface works as expected.

Core Concepts of Crontab

Crontab Time Expression Syntax

Every crontab entry begins with five time fields: minute, hour, day of month, month, and day of week. These fields accept integers, ranges ( 1-5), lists ( 0,15,30), and step values ( */10). The expression 0 2 * * * means "at minute 0 of hour 2, every day." See the Crontab expression referencefor the complete syntax.

User Crontab vs System Crontab

Each user on the system has an independent cron table, edited with crontab -e. The root user has a separate crontab. System-wide cron jobs live in /etc/crontab and /etc/cron.d/— these files include an additional username field between the time expression and the command. The Logrotatetool uses a system cron job in /etc/cron.daily/ to trigger log rotation.

Crontab Environment Differences

The cron daemon executes jobs with a minimal environment. The PATH variable defaults to /usr/bin:/bin— it does not include /usr/local/bin, /snap/bin, or any user-customized paths. The cron daemon does not load .bashrc, .profile, or .bash_profile. This environment difference is the single most common cause of crontab jobs not running.

Common Tasks with Crontab

How to List Active Cron Jobs with Crontab

Display all cron jobs for the current user:

crontab -l

How to Edit the Cron Table with Crontab

Open the current user's cron table in the default editor:

crontab -e

How to Schedule a Script to Run Daily with Crontab

Add a line to the cron table that runs a backup script at 2:00 AM every day, logging output to a file:

0 2 * * * /home/user/scripts/backup.sh >> /home/user/logs/backup.log 2>&1

For detailed instructions, see How to schedule a script with crontab.

Crontab Troubleshooting

ErrorCauseFix
Job does not execute at scheduled timeMissing PATH, wrong file permissions, no shebang line, or cron daemon not running→ Full article
"command not found" in cron logThe command's directory is not in cron's minimal PATHSet PATH in crontab or use absolute paths
Job runs at wrong timeSystem timezone mismatch or reversed minute/hour fieldsCheck timedatectl; verify field order in crontab expression
No output or email from cron jobOutput not redirected and no MTA configuredAppend >> /path/to/log 2>&1 to the crontab entry

The Logrotatetool relies on cron to trigger scheduled log rotation — logrotate failures often trace back to crontab issues. The at command handles one-time delayed execution, while crontab handles recurring schedules. On systemd-based systems, systemd timers offer an alternative with integrated logging via journalctl.