Cron Jobs

Cron Jobs

Cron is the standard Unix scheduler for running commands at fixed times or intervals. Every Ubuntu server uses cron extensively: logrotate runs nightly, apt security updates run weekly, and backup scripts run in the early morning hours. Understanding how to write reliable cron jobs — with proper environment setup, output handling, and error detection — is one of the most practical sysadmin skills because cron failures are silent by default and can go unnoticed for days.

How cron works

Cron daemon (crond):
  Reads crontab files every minute
  Executes commands matching current time
  Sends output to user's local mail (or /dev/null if redirected)

Crontab locations:
  /etc/crontab          → System crontab (has extra 'user' field)
  /etc/cron.d/          → Package-installed cron jobs
  /etc/cron.daily/      → Scripts run once per day
  /etc/cron.weekly/     → Scripts run once per week
  /etc/cron.monthly/    → Scripts run once per month
  /var/spool/cron/crontabs/  → Per-user crontabs (edit with crontab -e)

Crontab syntax

# Crontab format:
# minute  hour  day-of-month  month  day-of-week  command
#  0-59   0-23     1-31       1-12      0-7
#  (0 and 7 both = Sunday)

# Examples:
0 2 * * *        /usr/local/bin/backup.sh         # 2:00 AM every day
0 3 * * 0        /usr/local/bin/weekly-report.sh  # 3:00 AM every Sunday
*/15 * * * *     /usr/local/bin/health-check.sh   # Every 15 minutes
0 0 1 * *        /usr/local/bin/monthly-clean.sh  # Midnight on 1st of month
30 6 * * 1-5     /usr/local/bin/workday-tasks.sh  # 6:30 AM Mon-Fri
@reboot          /usr/local/bin/startup-tasks.sh  # On every system boot
@hourly          /usr/local/bin/hourly-check.sh   # Equivalent to: 0 * * * *

Managing cron jobs

# Edit your user's crontab:
crontab -e

# View current user's crontab:
crontab -l

# Edit root's crontab:
sudo crontab -e -u root

# List root's crontab:
sudo crontab -l

# Remove all entries from crontab (careful!):
crontab -r

# Check if cron daemon is running:
systemctl status cron

# View cron execution log:
grep CRON /var/log/syslog | tail -20

cron log output

Jun  9 02:00:01 web-01 CRON[12345]: (root) CMD (/usr/local/bin/backup.sh)
Jun  9 02:00:01 web-01 CRON[12346]: (root) CMD (/usr/local/bin/backup.sh > /var/log/backup.log 2>&1)

Cron best practices

# Always use full paths — cron has a minimal PATH:
# BAD:  0 2 * * * backup.sh
# GOOD: 0 2 * * * /usr/local/bin/backup.sh

# Redirect output — without redirection, cron mails output locally
# and errors are never seen:
0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# Set environment variables at top of crontab:
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=""    # Suppress email output (or set to your email)

# Use flock to prevent overlapping runs:
0 * * * * flock -n /var/run/backup.lock /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
# flock -n: exit immediately if lock already held (skip this run)

# Test a cron job manually before scheduling:
# Run as the same user cron would use:
sudo -u root /usr/local/bin/backup.sh
# Verify it works without the interactive environment

Conclusion

The two most common cron mistakes: using relative paths (cron has a minimal PATH that does not include /usr/local/bin) and not redirecting output (cron silently discards stdout/stderr unless you explicitly redirect or set MAILTO). Fix both with PATH= at the top of your crontab and >> /var/log/job.log 2>&1 on every command. Use flock for any job that could run longer than its interval to prevent multiple instances piling up.