Cron Jobs: The Complete Guide to Scheduling Tasks in Linux

Cron is the time-based job scheduler in Unix-like systems. It has been a cornerstone of Linux administration since the 1970s, and it remains the go-to solution for running recurring tasks — from log rotation and database backups to cache purges and monitoring checks. Despite its simplicity, cron has subtle behaviors that trip up even experienced engineers.

This guide covers everything from the five-field expression format to production-grade best practices that prevent the silent failures that make cron jobs notorious.

The Five-Field Cron Expression

A cron expression consists of five fields that define when a job runs. Each field represents a unit of time:

Special characters include * (any value),, (list),- (range), and/ (step). For example,*/15 means "every 15 units."

Practical Examples

Managing Crontabs

Each user has their own crontab. The system also has crontab files in/etc/cron.d/ and time-based directories like/etc/cron.daily/.

For system-wide jobs, placing scripts in /etc/cron.d/ with a username field is often cleaner than editing root's crontab directly. These files survive package upgrades and are easier to manage with configuration management tools like Ansible.

The Environment Problem

The number one reason cron jobs fail silently: cron runs with a minimal environment. Your interactive shell has PATH, environment variables, and shell configurations loaded from.bashrc or.profile. Cron does not load any of these.

Always use absolute paths for both the command and any files it references. If your script depends on environment variables, define them at the top of the crontab or source a config file at the beginning of your script.

Output and Logging

By default, cron sends any output (stdout and stderr) to the user's local mailbox. On most modern servers, local mail is not configured, so this output is silently lost. Always redirect output explicitly:

Never redirect to /dev/null unless you have separate monitoring in place. Silent failures in cron jobs can go unnoticed for weeks or months.

Preventing Overlapping Runs

If a cron job takes longer than its interval, you can end up with multiple copies running simultaneously. This is dangerous for jobs that modify databases, move files, or hold locks. Useflock to prevent overlap:

For critical jobs, combine flock with alerting: if the lock is held for longer than expected, your monitoring should flag it.

Cron vs. Systemd Timers

Modern Linux distributions offer systemd timers as an alternative to cron. Here is when each makes sense:

Use cron for simple, portable tasks. Use systemd timers when you need dependency ordering, built-in logging, resource controls (CPU/memory limits), or accurate sub-minute scheduling.

Production Best Practices