Crontab

Crontab — short for cron table — is the file that stores the schedule of jobs executed by the cron daemon, and simultaneously the command-line utility used to manage that file. Every account on a Unix-like system can own its personal crontab; alongside them live the system-wide /etc/crontab and package drop-ins under /etc/cron.d.

How crontab works

You never edit the stored file by hand — the spool location (typically /var/spool/cron/crontabs/) is private to the daemon. Instead, the crontab command mediates all changes:

• crontab -e — open your schedule in an editor; syntax is validated on save,
• crontab -l — print the current entries,
• crontab -r — remove the entire schedule, instantly and without confirmation,
• crontab -u alice -e — edit another user's schedule (root only).

Each non-comment line is one cron job: five time fields followed by the command. Beyond jobs, a crontab may define environment variables. MAILTO tells cron where to email each job's output and errors, PATH fixes the notoriously minimal default search path, and SHELL selects the interpreter. Lines starting with # are comments — use them generously, because six months later nobody remembers what sync2.sh was for.

Practical applications

The crontab is effectively the automation manifest of a server account: reading it tells you what backups run, when logs rotate, which application schedulers tick and what data syncs happen overnight. On a VPS you manage it directly over SSH; shared hosting panels such as cPanel, DirectAdmin or Plesk provide a form-based editor that writes to the same underlying file.

Habits that save real pain:

• export a copy regularly (crontab -l > crontab.backup) or keep the schedule in version control — crontab -r sits one keystroke away from crontab -e and deletes everything,
• set MAILTO or redirect job output to log files so failures are visible,
• comment every entry with its purpose and owner,
• after any edit, confirm in the system log that the job fired at the expected time.

Administrators of multi-user machines can additionally control who may use crontabs at all via /etc/cron.allow and /etc/cron.deny.