How to Set Up a Cron Job in Linux (Step by Step)

By CronHub Tools · Updated 2026-08-04

Setting up a cron job in Linux takes about two minutes: open your crontab with crontab -e, add one line containing a schedule and a command, and save. From that moment, Linux runs your task automatically — no further effort required.

This cron tutorial walks through each step in detail, shows you how to verify the job actually runs, and covers the beginner mistakes that make most first cron jobs fail silently.

How to Set Up a Cron Job in 5 Steps

1. Open your crontab for editing:

   crontab -e

2. Choose an editor if prompted (nano is the easiest — pick option 1 on Ubuntu).
3. Add one line with five time fields and your command:

   0 2 * * * /home/user/scripts/backup.sh >> /home/user/logs/backup.log 2>&1

4. Save and exit (in nano: Ctrl+O, Enter, then Ctrl+X). You should see crontab: installing new crontab.
5. Verify it was saved:

   crontab -l

That's the whole process. Now let's unpack what each step does and how to make your linux scheduled task bulletproof.

Step 1: Understand What You're Editing

crontab -e opens your user's personal cron table. Jobs in it run under your account, with your permissions. Each user on the system has their own crontab, and root has one too (sudo crontab -e).

Don't edit files in /var/spool/cron/ directly — the crontab command validates your syntax and tells the cron daemon to reload. Editing by hand skips both safety nets.

Step 2: Write the Schedule

The five fields before the command are, in order: minute, hour, day of month, month, day of week.

┌─ minute (0–59)
│ ┌─ hour (0–23)
│ │ ┌─ day of month (1–31)
│ │ │ ┌─ month (1–12)
│ │ │ │ ┌─ day of week (0–7)
│ │ │ │ │
0 2 * * *  →  every day at 2:00 a.m.

A few schedules you'll reach for constantly when you create cron jobs:

*/10 * * * *   # every 10 minutes
0 * * * *      # every hour, on the hour
0 9 * * 1-5    # weekdays at 9 a.m.
@daily         # shorthand for midnight every day

Step 3: Write the Command Properly

This is where most new cron jobs break. Cron runs your command with a minimal environment — a short PATH, no aliases, and no shell profile. Three rules keep you safe:

• Use absolute paths for programs. Write /usr/bin/python3, not python3. Find the full path with which python3.
• Use absolute paths for files. Cron's working directory is your home directory, not where your script lives.
• Capture the output. Append >> /path/to/logfile 2>&1 so both normal output and errors land in a file you can read.

A complete, production-quality entry looks like this:

30 1 * * * /usr/bin/python3 /home/user/app/cleanup.py >> /home/user/logs/cleanup.log 2>&1

Step 4: Save and Confirm

When you save and exit the editor, crontab installs the new table immediately. The cron daemon notices the change on its own — you never need to restart anything.

Confirm your job is registered:

crontab -l

If you see your line, the job is live. To remove all jobs later, crontab -r wipes your crontab (careful — there's no undo), or just delete individual lines with crontab -e.

Step 5: Verify the Job Actually Runs

Don't wait until 2 a.m. to find out your backup failed. Test with a fast schedule first:

* * * * * /home/user/scripts/backup.sh >> /tmp/test.log 2>&1

Wait a minute or two, then check:

head -50 /tmp/test.log
grep CRON /var/log/syslog        # Debian/Ubuntu
journalctl -u cron --since "10 min ago"   # systemd systems

The syslog line proves cron launched the job; your log file proves the job worked. Once both check out, change the schedule to the real one.

Setting Environment Variables (Optional but Useful)

Your crontab can define variables above the job lines, and they apply to everything beneath:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=alerts@example.com

0 2 * * * /home/user/scripts/backup.sh >> /home/user/logs/backup.log 2>&1

SHELL matters if your commands use bash-isms (cron defaults to /bin/sh), PATH reduces the absolute-path burden, and MAILTO sends any un-redirected output to a mailbox someone actually reads. Note that cron does not load your .bashrc or .profile — these crontab variables are the supported way to shape the job's environment.

Common Mistakes (and Fixes)

• The job works in your shell but not in cron. Almost always a PATH or environment issue. Use absolute paths, or set PATH= at the top of your crontab.
• The script isn't executable. Fix with chmod +x /home/user/scripts/backup.sh, or invoke the interpreter directly: /bin/bash /home/user/scripts/backup.sh.
• A % in the command breaks it. Cron treats % as a newline. Escape it: date +\%F.
• You edited the wrong crontab. Jobs added with sudo crontab -e belong to root, not you. Check both if a job seems missing.
• Overlapping runs. If a job might still be running when the next one starts, wrap it in flock: */5 * * * * /usr/bin/flock -n /tmp/job.lock /home/user/scripts/job.sh.

Best Practices for Linux Scheduled Tasks

• Add a comment above every job: # Nightly DB backup — added 2026-07, owner: alex.
• Log everything, and rotate the logs so they don't grow forever.
• Schedule heavy jobs at odd minutes (e.g., 17 3 * * *) to avoid the top-of-the-hour pileup.
• Make scripts idempotent so an extra run never causes damage.
• For jobs that must survive reboots and missed windows, consider a systemd timer instead.

Conclusion

To set up a cron job in Linux: run crontab -e, add a line with five time fields and an absolute-path command, redirect the output to a log, save, and verify with crontab -l plus a quick every-minute test. Follow the absolute-path rule and the logging rule, and your first cron job will run exactly as scheduled.

Next, browse our crontab examples library for ready-made schedules, or keep our troubleshooting guide handy in case a job refuses to fire.

Frequently Asked Questions

Related guides

References

• man7.org — crontab(1) manual page — the crontab command reference
• Ubuntu Community Help Wiki — CronHowto — distro-specific guidance
• crontab.guru — validate your schedule before saving