Cron Jobs on Linux: A Guide to Creating Scheduled Tasks

Doing recurring jobs on a server — backups, log cleanup, report generation — by hand is both a waste of time and a source of errors. The standard way to automate these jobs on Linux is cron. This guide explains the cron job concept, crontab syntax and practical scheduling examples.

Related reading: systemd service management · Essential Linux server commands

What Is a Cron Job?

Cron is a scheduler service on Linux that runs a command or script at specific times. Each scheduled task is called a cron job. Jobs like "back up the database every night at 03:00" or "check system status every 5 minutes" are exactly cron's domain.

Each user has their own cron table (crontab); there is also the /etc/cron.d/ directory and the /etc/crontab file for system-wide jobs.

crontab Syntax

A cron line consists of five time fields and the command to run. The five fields, in order, are:

Writing * in a field means "every value". An expression like */5 means "every 5 units".

Practical Scheduling Examples

# Run the backup script every day at 03:00
0 3 * * * /opt/scripts/backup.sh

# Check every 15 minutes
*/15 * * * * /opt/scripts/check.sh

# Weekly report every Monday at 09:00
0 9 * * 1 /opt/scripts/report.sh

# At midnight on the 1st of every month
0 0 1 * * /opt/scripts/monthly.sh

Creating and Editing Cron Jobs

To edit your own crontab you use the crontab -e command. To list existing jobs you use crontab -l, and to delete all of them crontab -r. If you want to run a job with root privileges, you edit root's crontab with sudo crontab -e.

Cron Job Troubleshooting

If a cron job is not running, the fastest way to find the problem is to redirect the output to a log file:

# Write both normal output and errors to a log file
0 3 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

• The script works by hand but not in cron: Usually a PATH or path issue — use full paths.
• Permission error: Make sure the script has execute permission (chmod +x) and runs as the correct user.
• It does not run at all: Verify with crontab -l that the job is actually registered and that the cron service (cron / crond) is active.

Frequently Asked Questions

How do I know whether a cron job ran?

Redirect the output to a log file and check the file. System logs (journalctl -u cron or /var/log/syslog) also show when cron triggered the job.

Should I use cron or a systemd timer?

For most simple scheduling jobs cron is enough and practical. systemd timers offer more advanced dependency, logging and missed-run handling; they may be preferred in complex scenarios.

Do missed jobs run while the server was off?

Classic cron does not make up for missed jobs. When the server may be off, anacron or the Persistent option of systemd timers runs these jobs at boot.