Scheduling Tasks with cron

By the end of this lesson you'll be able to schedule commands to run automatically — every night, every 15 minutes, or once at startup — using cron's five schedule fields, special shortcuts, and a crontab that actually runs reliably.

Learn Scheduling Tasks with cron in our free Command Line course — an interactive lesson with worked examples, a practice exercise and a quick reference.

Part of the free Cli course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

What You'll Learn

1. The crontab: -e, -l and -r

Your personal schedule lives in a file called your crontab , but you never open that file by hand — you manage it with three commands. crontab -e edits it (this is how you add jobs), crontab -l lists it, and crontab -r removes it. Be careful: crontab -r deletes your entire crontab with no confirmation, and it's one key away from -e — a classic footgun. Back up first with crontab -l > backup.txt .

2. The Five Schedule Fields

Every cron line is five time fields followed by the command. The order, left to right, is always: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), and day-of-week (0-7, where both 0 and 7 mean Sunday). So 30 2 * * * means minute 30, hour 2, any day, any month, any weekday — i.e. 02:30 every day .

3. Field Syntax: *, Steps, Ranges & Lists

Each field accepts four building blocks. * means every value. */n is a step — */5 in the minute field means every 5 minutes. a-b is a range — 1-5 in day-of-week is Monday through Friday. And a,b,c is a list — 1,15,30 . Combine them to express almost any schedule you need.

4. Special Shortcuts: @daily, @reboot & Friends

For common schedules, cron offers shortcuts that replace all five fields. @reboot runs a job once when the system boots; @hourly , @daily , @weekly , @monthly , and @yearly are readable aliases — for example @daily is exactly 0 0 * * * . You still add the command after the shortcut.

5. Output, Email & Logging

By default, cron emails whatever a job prints (stdout and stderr) to the local user. Put MAILTO="you@example.com" at the top of the crontab to choose the recipient, or MAILTO="" to switch that mail off. More commonly, people send output to a log file by appending >> /var/log/task.log 2>&1 — where 2>&1 routes errors into the same log so nothing is lost.

6. cron's Minimal Environment (use absolute paths!)

This is the single most common reason a cron job "works in my shell but not in cron." cron runs with a minimal environment : a sparse PATH (often just /usr/bin:/bin ) and none of your ~/.bashrc or login settings. So always use absolute paths to your commands and scripts — /usr/bin/python3 /home/user/app/job.py — or set PATH= at the top of the crontab. As a fast contrast: at runs a command once at a future time, and systemd timers are a modern alternative on systemd-based Linux.

🎯 Your Turn: schedule a daily 2:30 AM backup

Fill in the two blanks marked ___ using the # 👉 hints, then read the line back left to right and check it matches the Output panel.

🎯 Your Turn: run a check every 15 minutes

Two blanks again: pick the step syntax for "every 15 minutes," and the redirect that appends output to a log. Then check the Output panel.

Pro Tips

• 💡 Always use absolute paths in cron jobs — to the program and the script. cron's PATH is not your shell's PATH.
• 💡 Log everything: append >> /var/log/task.log 2>&1 so you can read what happened instead of waiting on cron email.
• 💡 Back up before editing: run crontab -l > cron-backup.txt so a stray crontab -r can't wipe your schedule for good.
• 💡 Test the schedule, not just the script: set a job a minute or two out, confirm it fires, then move it to its real time.

Common Errors (and the fix)

• Job silently does nothing — usually cron's minimal environment. Use absolute paths to commands and scripts, and add >> /var/log/job.log 2>&1 to capture the real error.
• Accidentally wiped your crontab — you ran crontab -r (remove) instead of crontab -e (edit). They're one key apart; keep a backup from crontab -l .
• Wrong field order — the order is minute, hour, day-of-month, month, day-of-week. Writing the hour first is a common mix-up that schedules the job at the wrong time.
• Unexpected runs on a weekday-of-month rule — if you set both day-of-month and day-of-week to non- * values, cron runs when either matches, not both.
• Inbox full of cron mail — a noisy job is emailing its output. Set MAILTO="" at the top, or redirect output to a log file.

📋 Quick Reference

Concept

Syntax

Notes

Edit crontab

crontab -e

Add or change jobs

List crontab

crontab -l

Print your jobs

Remove crontab

crontab -r

Deletes ALL of it

Field order

min hr dom mon dow

Then the command

Every value

*

Matches all

Step

*/5

Every 5 (e.g. minutes)

Range

1-5

Mon-Fri in dow

List

1,15,30

Specific values

Daily shortcut

@daily

= 0 0 * * *

At boot

@reboot

Runs once at startup

Email output

MAILTO="..."

Empty = no mail

Log output

>> file 2>&1

Append out + errors

Frequently Asked Questions

Mini-Challenge: a weekday morning report

No blanks this time — just a brief and an outline. Build the full cron line that runs a report script at 8:00 AM on weekdays and logs its output. Plan each field in order, use the absolute path, and check your line against the target in the comments.

🎉 Lesson Complete!

• ✅ Manage jobs with crontab -e (edit), crontab -l (list), crontab -r (remove — careful!)
• ✅ The five fields are minute hour day-of-month month day-of-week , then the command
• ✅ Use * , steps */n , ranges 1-5 , and lists 1,15,30 to build any schedule
• ✅ Shortcuts like @reboot and @daily cover the common cases
• ✅ Control output with MAILTO or >> /var/log/file.log 2>&1 , and always use absolute paths
• ✅ Next lesson: Networking Commands — inspect and troubleshoot connections with ping , curl , and friends

Practice quiz

Continue this course

• Previous: SSH and Remote Access
• Next: Networking Commands

Related lessons

• Lesson 7: Shell Scripting Basics