`crontab -e` Is Still the Command You Use When a Simple Scheduled Task Does Not Need a Whole Platform Around It
A practical guide to `crontab -e` for setting up recurring scripts, backups, and maintenance tasks without pretending every schedule needs a workflow orchestrator.
Why this command matters: developers increasingly overbuild scheduling for jobs that are, in truth, just a script that should run at a predictable time.
If you need to rotate logs, sync files, kick off a backup, ping a health endpoint, or run a small maintenance script every night, cron is still useful. It is not glamorous. It is also not dead.
The entry point most people need is crontab -e.
Edit the current user's cron table
crontab -eThis opens the user's crontab in an editor so you can add scheduled lines.
A basic example:
0 2 * * * /usr/local/bin/backup-script.sh >> /tmp/backup.log 2>&1That runs every day at 02:00, appending stdout and stderr to a log file.
Why cron jobs fail more than people expect
Cron is simple, but the environment it runs in is not the same as your interactive shell. That is where many failures come from:
PATHis smaller than expected- environment variables are missing
- relative paths break
- the script assumes a working directory that cron never set
This is why jobs “work manually” and then mysteriously fail under cron.
Better cron habits
Use absolute paths everywhere:
*/10 * * * * /usr/bin/curl -fsS https://example.com/health >> /tmp/healthcheck.log 2>&1If a script depends on a directory, set it explicitly inside the script:
#!/bin/bash
cd /opt/my-app || exit 1
/usr/bin/python3 jobs/daily_task.pyDo not assume cron knows where your project lives.
Useful companion commands
List current cron jobs:
crontab -lRemove the current user's crontab carefully:
crontab -rThat last one is destructive, so it deserves respect.
When cron is still the right answer
Cron is a good fit when:
- one machine owns the task
- the job is simple
- failure handling is lightweight
- you do not need distributed orchestration
If you need retries, stateful workflows, or cluster-aware scheduling, use something stronger. But do not force every 5-line scheduled script into infrastructure theater.
Final recommendation
If the task is simple and machine-local, crontab -e is still a perfectly respectable way to schedule it. Just remember that cron's stripped-down environment is exactly why careless jobs fail.