How to set up a cron job on Linux

Cron is the scheduler built into every Linux and macOS system. Setting up a job takes about a minute once you know the three moving parts: the crontab (your list of jobs), the schedule (five fields), and the command to run. Here's the whole process, start to finish.

Your first cron job

Open your personal crontab for editing:

crontab -e

The first time, it asks which editor to use — pick nano if you're unsure. Add a line at the bottom:

*/5 * * * * /usr/local/bin/backup.sh

Save and exit. That's it — the job now runs every 5 minutes. Cron re-reads the file automatically; there's nothing to restart.

Each line is a schedule followed by a command. The schedule is five space-separated fields — minute, hour, day-of-month, month, day-of-week — covered in full in the cron syntax guide. The command is run by /bin/sh, so it should be a full command line, ideally with absolute paths.

Managing your crontab

Three commands cover day-to-day use:

crontab -l     # list your current jobs
crontab -e     # edit them
crontab -r     # remove ALL of them (careful — no confirmation)

Each user has their own crontab, and jobs run as that user. A job in your crontab runs as you; a job in root's crontab (sudo crontab -e) runs as root.

System-wide cron

Personal crontabs are perfect for one user's jobs. For system tasks, Linux offers a few extra locations:

• /etc/crontab and /etc/cron.d/* — system crontabs. These have one extra field: a username between the schedule and the command, so cron knows who to run as.

  0 3 * * * root /usr/local/bin/nightly-maintenance.sh
  

• /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.weekly/, /etc/cron.monthly/ — drop an executable script into one of these directories and it runs on that cadence, no schedule line needed.

Use personal crontabs for your own jobs and /etc/cron.d for anything you ship as part of a package or deployment.

Make sure it actually runs

This is the step people skip — and then wonder why nothing happened. Cron fails silently, so verify:

1. Capture the output. By default cron tries to email output, which usually goes nowhere. Redirect it to a log instead:

   */5 * * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
   

   The 2>&1 captures errors, not just normal output — this is what tells you why a job failed.

2. Use absolute paths. Cron runs with a minimal PATH (often just /usr/bin:/bin), so node, python3 or aws may not be found. Use /usr/local/bin/node, or set PATH at the top of the crontab.

3. Test with a fast schedule. While setting up, schedule the job for every minute and watch the log. Once it works, change it to the real cadence.

Next steps

• Browse the example library for ready-made schedules to copy.
• Read the 7 most common cron mistakes before you rely on a job.
• Paste your expression into the parser to confirm the next run times match what you intended.