crontab -e is the right way to modify a crontab. It opens the user’s crontab in the default editor, validates the syntax on save, and refuses to install a broken crontab. The wrong way: editing /var/spool/cron/crontabs/<user> (or /etc/crontab) directly. The team that has been burned by a typo that silently disabled all cron jobs uses -e every time.
Table of contents
- The crontab -e command
- Listing the current crontab
- Removing the crontab entirely
- Editing the system crontab (root only)
- Crontab syntax refresher
- How this fits the rest of the stack
- FAQ
The crontab -e command
crontab -e
This opens the current user’s crontab in $VISUAL or $EDITOR (default: vi). The editor is launched with a copy of the crontab. When the editor exits, cron checks the syntax and installs the new version if it is valid. If the syntax is broken, cron refuses to install and asks the user to retry.
The team that has set EDITOR=vim in their shell rc gets vim. The team that has not gets vi. The team that prefers nano runs EDITOR=nano crontab -e for the one session.
Listing the current crontab
crontab -l
Prints the current user’s crontab to stdout. The team that scripts a backup of all crontabs runs crontab -l > backup.cron before any change.
The -l is the most underused crontab flag. The team that debugs a missing job always runs it first - half the time the crontab is empty because the previous edit failed silently.
Removing the crontab entirely
crontab -r
Removes the current user’s crontab. The team that uses this for a clean slate confirms the crontab is empty with crontab -l afterward. There is no confirmation prompt - the crontab is gone the moment the command runs.
The safer variant: crontab -r -i (interactive, asks for confirmation). The team that scripts cron teardowns uses this to avoid deleting the wrong user’s crontab by accident.
Editing the system crontab (root only)
The system crontab at /etc/crontab has a slightly different format (an extra user column). The team that edits it uses sudo vi /etc/crontab, not crontab -e (which edits the per-user crontab).
Other system-level cron locations:
-
/etc/cron.d/- drop a file here for a one-off system job -
/etc/cron.daily/,/etc/cron.hourly/,/etc/cron.weekly/,/etc/cron.monthly/- run-parts targets
The team that adds a system job puts a file in /etc/cron.d/ rather than editing /etc/crontab directly. The file in cron.d/ has the same format as /etc/crontab (with the user column).
Crontab syntax refresher
Five time fields plus the command:
* * * * * command
│ │ │ │ │
│ │ │ │ └── day of week (0-6, Sun=0)
│ │ │ └──── month (1-12)
│ │ └────── day of month (1-31)
│ └──────── hour (0-23)
└────────── minute (0-59)
Common schedules: 0 * * * * (every hour), 0 0 * * * (midnight daily), */5 * * * * (every 5 minutes), 0 9-17 * * 1-5 (9-5 weekdays).
The team that scripts the schedule reads the man page (man 5 crontab) once. The team that guesses the syntax is the team that sets up a job that runs every minute forever.
FAQ
Can I edit the crontab file directly?
Technically yes - the file is at /var/spool/cron/crontabs/<user> (Linux) or /var/cron/tabs/<user> (BSD). But the cron daemon re-reads the crontab only when crontab updates the file. Direct edits get overwritten or ignored. Always use crontab -e.
Why does crontab -e refuse to save my edit?
Cron validates the syntax on save. If the new crontab has a bad line (wrong number of fields, invalid time value, etc.), cron refuses to install and asks the user to re-edit. The fix: fix the syntax. The team that sees this error has a typo in a time field.
Where does cron output go?
By default, the cron daemon emails the job output to the local user. The team that does not want email redirects to a file: 0 5 * * * /opt/backup.sh >> /var/log/backup.log 2>&1. The team that does not have a local MTA (mail transfer agent) configured gets an email-send failure silently.
Can two users have different crontabs?
Yes. Each user has their own crontab. crontab -e (no sudo) edits the current user’s. sudo crontab -e -u otheruser edits another user’s. The team that manages a multi-user server has separate crontabs per user.
What is the difference between /etc/crontab and crontab -e?
/etc/crontab is the system crontab - one file, edited with sudo vi /etc/crontab, with an extra user column. crontab -e is the per-user crontab - stored in /var/spool/cron/, with no user column (cron knows the user from the file path).
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: