Cheatsheet: Crontab

In order: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where both 0 and 7 mean Sunday depending on implementation -- Vixie cron accepts both). A job runs when the current time matches every field, except that if both day-of-month and day-of-week are restricted (not *), the job runs when either one matches, not only when both match.

*/5 is a step value meaning 'every 5th value starting from the field's minimum', so in the minute field it runs at :00, :05, :10, ... :55 -- identical to listing 0,5,10,15,20,25,30,35,40,45,50,55. Steps are shorthand for evenly-spaced values; they don't change behavior, just save typing. */5 in the hour field means every 5th hour starting at 0 (0,5,10,...), not every 5 hours from whenever the job was installed.

crontab -e opens your user crontab in $EDITOR (falls back to vi); crontab -l lists it without opening an editor; crontab -r removes it entirely (no confirmation on most systems, so back it up with crontab -l > backup.cron first). User crontabs live under /var/spool/cron/crontabs/<user> (Debian/Ubuntu), /var/spool/cron/<user> (RHEL), or /usr/lib/cron/tabs/<user> (macOS) and should never be edited directly there -- always go through crontab -e so the cron daemon picks up the change and file permissions stay correct.

The most common causes: (1) cron runs with a minimal environment, not your login shell's PATH, so a bare command name that works in your terminal can fail silently in cron -- use full paths (/usr/bin/python3) or source your profile first; (2) output isn't going anywhere, so errors are invisible unless you redirect stdout/stderr (see the redirection examples below) or rely on cron's default mail-on-output behavior (which requires a working local MTA); (3) the day-of-month/day-of-week OR-logic surprises people when both fields are restricted; (4) missing a trailing newline at the end of the crontab file, which some cron implementations require.

They're shorthand for common five-field schedules: @reboot runs once when the cron daemon starts (e.g. after a system reboot) rather than on a schedule; @yearly/@annually = '0 0 1 1 *'; @monthly = '0 0 1 * *'; @weekly = '0 0 * * 0'; @daily/@midnight = '0 0 * * *'; @hourly = '0 * * * *'. They're purely readability sugar -- cron expands them internally to the equivalent five-field expression, so you can always fall back to explicit fields for anything they don't cover.