How to Schedule Tasks in Linux with Cron

Cron is the classic Linux scheduler that runs commands automatically at set times, from backups every night to a script every five minutes. Once you understand its simple syntax, you can automate almost any recurring task. Here’s how to use it effectively.

Understanding the Crontab Format

Each scheduled job lives in a crontab (cron table) and follows a five-field timing pattern, then the command:

Read also: Testing Multiple Linux Distributions Is Now Possible Without Even Closing Your Browser, with DistroSea

* * * * * command-to-run

The five fields, in order, are:

1. Minute (0–59)
2. Hour (0–23)
3. Day of month (1–31)
4. Month (1–12)
5. Day of week (0–7, where 0 and 7 both mean Sunday)

An asterisk means “every.” Special characters refine the schedule: */5 means “every 5 units,” 1-5 is a range, and 1,15 is a list of specific values.

Editing Your Crontab

Don’t edit cron files by hand. Use the dedicated command, which validates your entries:

• crontab -e — open your personal crontab in the default editor.
• crontab -l — list your current jobs.
• crontab -r — remove your crontab entirely (use with care).
• sudo crontab -e -u username — edit another user’s crontab.

Save and close the editor, and cron immediately picks up the changes. There’s no service to restart.

Practical Schedule Examples

These cover the most common needs:

• 0 2 * * * /home/user/backup.sh — run a backup every day at 2:00 AM.
• */15 * * * * /usr/local/bin/check.sh — run every 15 minutes.
• 0 9 * * 1-5 /home/user/report.sh — run at 9 AM on weekdays only.
• 30 23 1 * * /home/user/monthly.sh — run at 11:30 PM on the 1st of each month.
• 0 0 * * 0 /home/user/weekly.sh — run every Sunday at midnight.

Cron also accepts handy shortcuts in place of the five fields: @daily, @hourly, @weekly, @monthly, and @reboot (which runs once at every boot).

Avoiding Common Pitfalls

Most cron failures come from environment differences, because cron runs with a minimal PATH and no interactive shell setup.

• Use absolute paths for both the command and any files it touches, e.g. /usr/bin/python3 /home/user/job.py instead of python3 job.py.
• Capture output to debug: append >> /home/user/job.log 2>&1 so you can see errors.
• Escape the percent sign — in cron, % has special meaning and must be written as \%.
• Check the mail/log — failed jobs may email output to the user, and system cron activity is logged in /var/log/syslog or via journalctl -u cron.

Alternatives Worth Knowing

On modern systems, systemd timers offer a more powerful alternative with better logging and dependency handling, configured via .timer and .service units. For one-off scheduling rather than recurring jobs, the at command runs a task once at a specified future time, for example echo "/path/script.sh" | at 22:00.

Frequently Asked Questions

How do I run a cron job every 5 minutes?

Use */5 * * * * command. The */5 in the minute field tells cron to run the command at every fifth minute of every hour.

Why does my script work manually but fail in cron?

Cron runs with a stripped-down environment and minimal PATH. Use absolute paths for every command and file, and redirect output to a log with 2>&1 to see the actual error.

Where can I see if my cron jobs ran?

Check the system log with grep CRON /var/log/syslog on Debian/Ubuntu or journalctl -u cron. Adding your own log redirection to each job makes debugging far easier.

What’s the difference between cron and systemd timers?

Cron is simple and universal, while systemd timers integrate with the service manager for richer logging, retries, and dependencies. Use cron for quick tasks and timers when you need more control.