The 5 places cron jobs are saved
Cron capabilities and best-practices have evolved over 40+ years, leaving you with several options when scheduling (or looking for) a cron job. This guide will walk you through the five different places cron jobs can be scheduled on most systems today.
The user crontab file
In Linux, each user has their own crontab that can be used to schedule jobs that will be run as that user. On Debian and Ubuntu those files are stored in /var/spool/cron/crontabs, one file per account. On Red Hat and Fedora the directory is /var/spool/cron, with the same one-file-per-user layout. You should not update these files directly. View, update, and delete a user crontab with the crontab command.
Viewing your user crontab
$ crontab -l
0 9 * * * /var/cronitor/bin/water-the-plants.py
0 7 * * 6 /var/cronitor/bin/take-out-the-garbage.py
Viewing another user's crontab
$ crontab -u tstark -l
0 0 * * * /jarvis/reboot-arc-reactor
Editing your user crontab
$ crontab -e
# This will open your default editor, usually vi or nano
If your server has a lot of users it could be challenging to find the right one. If you can see the job details in your cron logs, the username may be included. In the example below you can see the ubuntu user running the database backup script:
Aug 5 4:05:01 dev01 CRON\[2128\]: (ubuntu) CMD (/var/cronitor/database-backup.sh)
To update a user crontab, use crontab -e. The cron files themselves should not be updated directly. Using crontab -e will validate your changes and signal cron to reload your file.
Want alerts if your cron jobs stop working?
Monitor your cron jobs with Cronitor to easily collect output, capture errors and alert you when something goes wrong.
The root user crontab
Like any other user, root has a user crontab. Essentially the same as any other user crontab, you are editing the root crontab when you run sudo crontab -e.
Jobs scheduled in the root user crontab will be executed as root with all of its privileges.
In /etc/cron.*
If your system has /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly directories, these can be used to schedule jobs by copying or symlinking a script or command. The scripts run as root, because /etc/crontab says so.
On Debian and Ubuntu the jobs in /etc/crontab look like this. The minute and hour on your host may differ. The command is run-parts --report, and the daily, weekly, and monthly lines are skipped when anacron is installed, because anacron runs those itself:
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
System crontab file
The original and still commonly used way to schedule system-wide cron jobs is by adding entries to the crontab file /etc/crontab.
Writing to /etc/crontab requires admin privileges and jobs scheduled here can be run as any user. The username is a required field, the first word after the schedule. It does not default to root. In this example the backup runs once a day at midnight as dataproc:
0 0 * * * dataproc /var/cronitor/bin/database-backup.sh
System drop-in directory /etc/cron.d
Another common way to schedule system-wide cron jobs is by adding a crontab file to /etc/cron.d.
Like jobs scheduled in /etc/crontab, writing to /etc/cron.d requires elevated privileges and the first word after the expression of each cron job must specify which user will run the job.
On Debian and Ubuntu, cron skips a file in /etc/cron.d when the name contains anything other than letters, digits, underscores, and hyphens (backup.sh never runs), when the file is not owned by root, or when group or other users can write it.
Tip: For installers and scripts, adding a file to /etc/cron.d is a much cleaner option than adding entries to crontab files.
What is the crontab
When individual user crontabs are edited using crontab -e, the files are stored in /var/spool/cron/crontabs on Debian and Ubuntu, and in /var/spool/cron on Red Hat and Fedora.
You can look, but avoid the temptation to edit crontab files here directly and always use crontab -e. If you edit files in /var/spool/cron directly you will lose the benefit of syntax checking that the crontab editor provides, and your changes will not be detected without sending a reload signal to the cron daemon.