Skip to main content
Running a task once is useful, but in production systems many jobs must run repeatedly: nightly backups, weekly log rotation, or health checks every minute. Automating these recurring tasks is essential. This guide explains how to schedule recurring jobs using cron — the standard UNIX job scheduler — and how to manage both per-user and system-wide crontabs. Cron is driven by the cron daemon (crond), which checks crontab files once a minute and runs any jobs scheduled for the current time. Jobs are defined in crontab files — plain-text lists that describe when commands should run.
A dark-themed diagram titled "Crontab" showing a "cron daemon" box that reads "crontabs" and arrows to text boxes explaining that cron allows scheduling of jobs and crontabs are a list of jobs and when they should run.

​
Where crontab files live

Use the following locations depending on whether you need per-user jobs, periodic scripts, or system-wide jobs:

​
Managing user crontabs with the crontab command

Use the crontab helper to edit, list, or remove a user’s crontab:
  • crontab -e — edit the current user’s crontab (opens the editor defined by $EDITOR).
  • crontab -l — list the current user’s crontab.
  • crontab -r — remove the current user’s crontab.
  • crontab -r -u username — remove another user’s crontab (requires root).

​
Crontab format: schedule fields and command

Each non-comment line in a crontab defines one job. The first five whitespace-separated fields set when the job runs:
  • In a per-user crontab, the sixth field onward is the command to execute.
  • In a system crontab (such as /etc/crontab or files under /etc/cron.d/), the sixth field is the user account to run the command as, and the rest form the command.
Example — user crontab (fields: minute hour day month weekday command):
Example — system crontab or /etc/cron.d file (fields: minute hour day month weekday user command):

​
Special characters and common patterns

  • * — every unit (every minute, every hour, etc.).
  • - — range (e.g., 9-17 for hours 9 through 17).
  • / — step values (e.g., */10 for every 10 minutes).
  • , — list values (e.g., 11,12 for minute 11 and 12).
  • You can combine ranges, steps, and lists in one field.

​
Using run-parts for periodic directories

Many Linux distributions use run-parts to execute scripts placed in periodic directories:
  • /etc/cron.hourly
  • /etc/cron.daily
  • /etc/cron.weekly
  • /etc/cron.monthly
Place executable scripts (not plain text) in the appropriate directory to run them at the matching interval. Ensure they have the proper shebang and executable permissions (e.g., chmod +x script).

​
Practical demo: create several user cron jobs

Below is a consolidated example showing how a user (student) might add recurring jobs with crontab -e. These examples demonstrate specific minutes/hours, intervals, ranges, and lists. Open the crontab for the student user:
Add the following lines to schedule several recurring jobs:
Save and exit the editor (for example, in vim: :wq). The new crontab is installed automatically. Verify the installed crontab:
Note: Each user can edit and list their own crontab. Only an administrative user (root) can edit or view another user’s crontab.
You can combine ranges, intervals, and lists in a single crontab entry. Always test commands manually to verify paths and behavior before scheduling them in cron.

​
System-wide cron jobs

For system-level scheduled tasks, prefer adding files to /etc/cron.d/ rather than editing /etc/crontab directly. Files placed in /etc/cron.d/ must use the system crontab format (i.e., include the user field). Example: create /etc/cron.d/sysjob that runs every 2 minutes as root.
Add the following to /etc/cron.d/sysjob:
Save the file. The cron daemon will pick up the new file automatically.

​
Removing a user’s crontab (as root)

To remove a specific user’s crontab as root:
After removal, the user will see:

​
Checking the cron daemon (crond)

On systemd-based systems, check the status of the cron daemon (name varies by distribution: crond or cron):
If jobs do not run as expected:
  • Confirm the cron service is active and enabled.
  • Inspect logs for cron-related activity (e.g., journalctl -u crond or /var/log/cron).
  • Make sure scripts in periodic directories are executable and have correct shebangs.
  • Use full paths in crontab commands and redirect stdout/stderr to files for easier debugging.

​
Wrap-up

You now know how to:
  • Write crontab schedule expressions and the meaning of each time field.
  • Manage per-user crontabs with crontab -e, -l, and -r.
  • Use run-parts for periodic scripts in /etc/cron.*.
  • Create system-wide cron jobs under /etc/cron.d/ or /etc/crontab.
  • Verify the cron daemon and troubleshoot scheduled jobs.
Further reading and references:

Watch Video