Crontab in Linux: Schedule Cron Jobs

Quick take: The crontab command schedules recurring jobs. Run crontab -e to edit your jobs, crontab -l to list them, and write each line as five time fields (minute, hour, day, month, weekday) followed by the command.

Introduction

Cron is the Linux job scheduler, and crontab is how you manage your personal schedule of recurring tasks — backups, cleanups, report generation, and health checks. Each user has their own crontab, and the system has its own for administrative jobs.

This guide explains editing your crontab, the five-field time syntax, the handy shorthand strings, and the pitfalls that catch newcomers.

Syntax

The basic syntax of the crontab command is:

crontab [OPTIONS]
# job line: minute hour day month weekday command

Understanding the Cron Time Fields

Each cron line begins with five time fields, in this order:

# ┌── minute (0-59)
# │ ┌── hour (0-23)
# │ │ ┌── day of month (1-31)
# │ │ │ ┌── month (1-12)
# │ │ │ │ ┌── day of week (0-7, 0 and 7 are Sunday)
# │ │ │ │ │
#   *   *   *   *   *   command-to-run

Use * for “every”, */n for “every n”, ranges like 1-5, and lists like 1,15,30. So 0 */6 * * * runs at the top of every sixth hour.

Common Options and Parameters

The most useful options and parameters for the crontab command:

Practical Examples

Real crontab commands you can run today:

# Edit your cron jobs
crontab -e
# List your cron jobs
crontab -l
# Run a backup every day at 2:30 AM
30 2 * * * /home/irfan/backup.sh
# Run every 15 minutes
*/15 * * * * /usr/local/bin/healthcheck.sh
# Run at 9 AM on weekdays only
0 9 * * 1-5 /home/irfan/report.sh
# Run a cleanup once a week using a shorthand
@weekly /home/irfan/cleanup.sh

User Crontabs vs System Cron

There is more than one place cron jobs live. Each user has a personal crontab managed with crontab -e, but the system also reads jobs from /etc/crontab and the /etc/cron.d/ directory, plus the convenience folders /etc/cron.daily/, cron.weekly/, and cron.hourly/.

The key difference is that system cron entries include an extra field — the user to run the job as — between the schedule and the command. Use a personal crontab for your own tasks, and /etc/cron.d/ for packaged, system-wide jobs that should run as a specific service account.

Debugging Cron Jobs That Do Not Run

A cron job that works in your shell but fails under cron is almost always an environment problem. cron runs with a minimal PATH and no profile, so commands that rely on your interactive setup break. The fixes are reliable:

• Use absolute paths for every command and file (/usr/bin/python3, not python3).
• Redirect output so errors are captured: * * * * * /path/job.sh >> /var/log/job.log 2>&1.
• Confirm the script is executable and check the system cron log (journalctl -u cron or /var/log/syslog).

Most “my cron job isn't running” problems disappear once paths are absolute and output is logged.

Tips and Best Practices

• Always use absolute paths in cron jobs — cron runs with a minimal environment and a different PATH than your shell.
• Redirect output to a log so you can debug: 30 2 * * * /path/script.sh >> /var/log/backup.log 2>&1.
• Test the schedule with a tool like crontab.guru, and remember the times use the server's timezone.

Final Thoughts

crontab automates the recurring work that keeps systems healthy. Learn the five time fields, the */n and range syntax, and the @daily shorthands, and you can schedule anything from a five-minute health check to a nightly backup. Use absolute paths and log the output, and your cron jobs will run reliably and be easy to debug.