cron (Scheduled tasks)

systemctl status cron

On Red Hat or CentOS systems, the service is called `crond`:

systemctl status crond

If cron is not running, start the service with:

sudo systemctl start cron
sudo systemctl enable cron

2. Show your current cron jobs

The command `crontab -l` displays the list of scheduled tasks for the current user.

crontab -l

If there are no tasks yet, you will get empty output or a message that no crontab is set.

3. Edit your crontab

Open your crontab in the default editor to add or modify tasks.

crontab -e

The first time, the system chooses an editor — usually `nano` or `vi`. You can explicitly choose an editor:

EDITOR=nano crontab -e

4. Understand the five-field format

Each line in a crontab has five time fields followed by the command. The fields are: minute, hour, day of the month, month, day of the week.

minute hour day-of-month month day-of-week command

An example line that runs a script every day at 02:00:

0 2 <em> </em> * /backup/scripts/daily.sh

The asterisks mean "every" — so every day of the month, every month, every day of the week.

5. Add a task

Add a line to your crontab for the task you want to schedule. Always use full paths to commands and scripts, because cron jobs run outside an interactive shell and `PATH` is limited.

0 2 <em> </em> * /usr/bin/backup-script.sh > /var/log/backup.log 2>&1

This line runs the script daily at 02:00 and writes both stdout and stderr to `/var/log/backup.log`. Without redirection, cron sends the output by email to the owner of the crontab — on systems without configured mail, those messages are lost.

6. Define environment variables if needed

Because cron jobs do not use an interactive shell, you can explicitly define variables such as `PATH` at the top of your crontab.

PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash
0 2 <em> </em> * /usr/local/bin/backup-script.sh

This prevents problems with commands not being found because they are outside the default `PATH`.

7. Use system-wide configuration directories

For system-wide administration, you can place tasks in `/etc/cron.d/`, `/etc/cron.hourly/`, `/etc/cron.daily/`, `/etc/cron.weekly/`, and `/etc/cron.monthly/`. Files in `/etc/cron.d/` use the same format as a crontab, but include a user field.

Create a file in `/etc/cron.d/`:

sudo nano /etc/cron.d/backup

Content:

0 2 <em> </em> * root /usr/local/bin/backup-script.sh

The `root` field indicates which user runs the task. Tasks in `/etc/cron.daily/` and similar directories run daily, weekly, and monthly respectively — the format in those files is different: there, only the script path is listed, no time fields.

8. Remove a task

Remove a specific line from your crontab with `crontab -e`, or remove all tasks for the current user:

crontab -r

Be careful: `crontab -r` removes the entire crontab without confirmation.

Verification

Check if your task is saved correctly:

crontab -l

Check if the task actually ran by viewing the logs. On Debian and Ubuntu systems, cron logs are in `/var/log/syslog`:

grep CRON /var/log/syslog

On Red Hat and CentOS systems, cron logging is in `/var/log/cron`:

grep CRON /var/log/cron

On systems with systemd, you can also consult the journal:

journalctl -u cron

On Red Hat systems:

journalctl -u crond

The log lines contain the timestamp, username, and the executed command — this way, you can see directly whether your task ran at the right time.

Common problems

Task is not executed

The most common cause is an error in the time format or a missing full path to the command. First, check if the command works manually from the shell, and then use the full path in the crontab. Then check the logs with `grep CRON /var/log/syslog` or `journalctl -u cron` to see if the task is picked up.

Output from tasks is lost

Without redirection, cron sends the output by email to the owner of the crontab. On systems without mail configuration, that output is lost. Redirect the output explicitly to a log file:

0 2 <em> </em> * /usr/local/bin/backup-script.sh >> /var/log/backup.log 2>&1

Missing environment variables

Cron jobs run without the variables from your interactive shell. Define `PATH`, `SHELL`, and other required variables at the top of your crontab, or use full paths to all commands in your script.

Cron has been part of Unix since 1975 — the original implementation by Brian Kernighan in Version 7 Unix read jobs from `/usr/lib/crontab` and checked that file every minute, and that per-minute check is still the core of modern implementations. The early version ran as a daemon in multi-user mode and executed all jobs with superuser privileges — a risk that modern systems mitigate by running jobs per user. On systems with systemd, timers offer a modern alternative, and in container environments such as Docker and Kubernetes, orchestrators like Kubernetes CronJobs often replace the traditional cron daemon. But for anyone who wants to schedule tasks simply and reliably on a Linux server, cron remains the foundation on which those alternatives ultimately build.