Scheduling: cron & at

cron - recurring jobs

Scenario: You need a database backup to run every night at 2 AM, forever, without anyone remembering to trigger it manually. That's exactly what cron is for - a background daemon that wakes up once a minute, checks a schedule, and runs anything that's due.

A crontab line has five time fields then the command to run:

┌ minute (0-59)
│ ┌ hour (0-23)
│ │ ┌ day of month (1-31)
│ │ │ ┌ month (1-12)
│ │ │ │ ┌ day of week (0-7, 0 & 7 = Sunday)
│ │ │ │ │
* * * * *  /path/to/command

A bare in any field means "every value" - so alone would mean "run every single minute of every day." Replacing a field with a specific number pins it to that value; the examples below show both.

crontab -e edits a per-user schedule - each user has their own, stored privately and run as that user. For system-wide jobs (run as any user you specify, and managed by administrators rather than individual users), the equivalents are /etc/crontab and the drop-in directory /etc/cron.d/, plus a set of convenience directories /etc/cron.{hourly,daily,weekly,monthly}/ where dropping in a script is enough - cron runs everything inside on that cadence automatically.

Examples:

0 2 * * *      backup.sh        # every day at 02:00
*/15 * * * *   check.sh         # every 15 minutes
0 9 * * 1-5    report.sh        # 09:00 on weekdays

The */15 syntax means "every 15 units" - so in the minute field, it fires at :00, :15, :30, :45. The 1-5 in the last example is a range (Monday through Friday), so that job only runs on weekdays, never weekends.

at - one-off jobs

Sometimes you don't want something recurring - just a single job scheduled for later. at covers that case that cron deliberately doesn't handle well.

$ echo 'reboot' | at 03:00
$ atq          # list pending
$ atrm 3       # remove job 3

Tip: cron's fixed five-field schedule is showing its age. Modern systemd-based distros offer systemd timers as an alternative (systemctl list-timers) - they get you the same recurring-job behavior, but log to the journal, can depend on other systemd units, and integrate with systemctl status like any other service. cron remains extremely common and worth knowing cold, but don't be surprised to see timers used instead on newer infrastructure.