Scheduling Tasks with cron

cron is the standard Unix time-based job scheduler, running as a background daemon (crond) that wakes up every minute, checks all registered crontabs, and launches any job whose schedule matches the current minute. It's the backbone of routine system automation on Linux — log rotation, backups, certificate renewal, report generation, cache warming — anything that needs to run on a fixed recurring schedule without a human triggering it. Each user can maintain their own crontab (edited via crontab -e), and the system also supports system-wide job definitions in /etc/crontab and /etc/cron.d/, plus convenience directories /etc/cron.{hourly,daily,weekly,monthly}/ for simple scripts that don't need custom timing.

Each line in a crontab has five time-and-date fields followed by the command to run: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), and day-of-week (0-7, where both 0 and 7 mean Sunday). An asterisk (*) means 'every value'; comma-separated lists (1,15) mean specific values; a hyphen (9-17) means a range; and a slash (*/15) means a step value — every 15 units starting from the field's minimum. All five fields must match the current time for the job to fire; unlike a simple interval timer, cron reasons purely in terms of matching absolute time fields, which is why 'every 15 minutes' is */15 in the minute field but 'every 15 days' has no direct equivalent (day-of-month doesn't divide evenly, so you'd typically use a script-level check instead).

/etc/crontab and files under /etc/cron.d/ are system-level crontabs with one extra field compared to a user crontab: after the five time fields comes the username the job should run as, before the command itself. This distinction matters — packages that install their own cron jobs (like logrotate or certbot) typically drop a file into /etc/cron.d/ rather than editing a user's personal crontab, because it's cleanly managed by the package manager (removed automatically on uninstall) and version-controllable. The /etc/cron.{hourly,daily,weekly,monthly}/ directories are simpler still: any executable script placed there runs on that cadence automatically via a single line in /etc/crontab that invokes run-parts.

cron supports convenient shorthand strings in place of the five time fields: @reboot (run once at startup), @daily (equivalent to 0 0 * * *), @hourly, @weekly, @monthly, and @yearly. For debugging a job that isn't firing, check grep CRON /var/log/syslog (Debian/Ubuntu) or journalctl -u cron / journalctl -u crond (RHEL family or systemd-based logging) to confirm cron actually attempted to launch it, verify the crontab syntax with crontab -l, and test the exact command cron would run in a minimal environment using env -i /bin/sh -c '<command>' to reproduce PATH-related failures locally.