CalcSnippets Search
Linux 2 min read

`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 -e

This 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>&1

That 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:

  1. PATH is smaller than expected
  2. environment variables are missing
  3. relative paths break
  4. 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>&1

If 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.py

Do not assume cron knows where your project lives.

Useful companion commands

List current cron jobs:

crontab -l

Remove the current user's crontab carefully:

crontab -r

That last one is destructive, so it deserves respect.

When cron is still the right answer

Cron is a good fit when:

  1. one machine owns the task
  2. the job is simple
  3. failure handling is lightweight
  4. 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.

Sources

Keep reading

Related guides