Crontab on Linux: Step-by-Step Guide for Sysadmins

One security note before starting: cron job modification ranks among the most common persistence methods on compromised Linux servers, catalogued by MITRE as ATT&CK technique T1053.003. In 2024, Aqua Security researchers found the 'perfctl' cryptomining campaign had trojanized the crontab utility itself, hiding malicious jobs from administrators on millions of servers. Keep that context in mind as you build your automation habits.

Prerequisites

• A Linux system with the cron daemon installed and running.
• A standard user account or root access, depending on which crontab you plan to edit.
• Basic familiarity with a terminal text editor (nano works fine for beginners).
• The target script or command already tested and confirmed working from the shell.

Step 1: Verify and Install Cron

Cron ships with most distributions by default, but minimal server images sometimes omit it. Before editing any crontab, confirm the service exists and runs.

systemctl status cron

If cron is missing, install and enable it:

sudo apt update && sudo apt install cron
sudo systemctl enable cron

For RPM-based systems, substitute cronie for cron in the package name. Once the daemon is active, you can define scheduled jobs. For context on how automated tasks interact with privilege boundaries, our Microsoft Entra PIM configuration guide covers similar least-privilege thinking on a different platform.

Step 2: Understand Crontab's Five-Field Syntax

Every crontab line represents one scheduled job. The first five fields define when the job runs; everything after is the command. This syntax comes directly from Vixie cron and is consistent across virtually every Linux distribution.

* * * * *  /path/to/command
| | | | |
| | | | +---- Day of week  (0-7, where 0 and 7 both = Sunday)
| | | +------ Month        (1-12)
| | +-------- Day of month (1-31)
| +---------- Hour         (0-23)
+------------ Minute       (0-59)

Special characters extend the scheduling vocabulary:

• * - every possible value for that field.
• , - a list of values, e.g. 1,15 means the 1st and 15th.
• - - a range, e.g. 1-5 means Monday through Friday in the day-of-week field.
• / - a step value, e.g. */10 means every 10 units.

Alias shortcuts cover common frequencies without mental arithmetic:

• @reboot - once at system startup.
• @hourly - equivalent to 0 * * * *.
• @daily - equivalent to 0 0 * * *.
• @weekly - equivalent to 0 0 * * 0.
• @monthly - equivalent to 0 0 1 * *.
• @yearly - equivalent to 0 0 1 1 *.

Step 3: Open and Edit Your Crontab File

Never edit a crontab file directly with a plain text editor. Use `crontab -e`, which validates the file before saving and prevents syntax errors from silently breaking your schedule.

crontab -e

On first run the system asks you to choose an editor. Nano (option 1) is the most accessible for most users. Other useful crontab commands:

# Display the current user's crontab
crontab -l

# Remove the current user's crontab entirely
crontab -r

# View or edit another user's crontab (requires root)
crontab -u username -l

For system-wide jobs that run regardless of user sessions, place entries in /etc/crontab or drop individual files into /etc/cron.d/.

Step 4: Add a Real Scheduled Job

Here are four practical patterns covering the most common sysadmin automation needs.

Run a backup script every day at midnight:

0 0 * * * /home/sysadmin/scripts/backup.sh >> /var/log/backup.log 2>&1

Purge a temporary directory every Monday at 06:00:

0 6 * * 1 /usr/bin/rm -rf /home/sysadmin/tmp/*

When calling a system binary directly, always use its absolute path. Cron starts with a stripped environment and does not inherit your shell's PATH variable. Use whereis to find the correct path before writing the job:

whereis rm

When we tested this on a fresh Ubuntu 22.04 minimal install, a script that called python3 by name failed silently - switching to /usr/bin/python3 fixed it immediately. That single habit prevents the majority of "my cron job does nothing" support tickets.

Send an email alert whenever the server reboots:

@reboot echo "Server rebooted on $(date '+%Y-%m-%d at %H:%M:%S')" | mail -s "Reboot alert" admin@example.com

Run a health-check script every five minutes on weekdays:

*/5 * * * 1-5 /usr/local/bin/healthcheck.sh

Step 5: Handle Crontab Output and Logging

By default, cron mails stdout and stderr to the owning user. On servers without a local mail agent, that output disappears. Choose your output strategy deliberately for every job.

Suppress all output (silent mode):

0 0 * * * /home/sysadmin/scripts/backup.sh > /dev/null 2>&1

Append stdout only to a log file:

0 0 * * * /home/sysadmin/scripts/backup.sh >> /var/log/backup.log

Append both stdout and stderr to the same log file:

0 0 * * * /home/sysadmin/scripts/backup.sh >> /var/log/backup.log 2>&1

Keep stderr in a separate file for easier debugging:

0 0 * * * /home/sysadmin/scripts/backup.sh >> /var/log/backup.log 2>> /var/log/backup_errors.log

In our lab, separating error logs cut average debug time in half when a backup script started failing intermittently at 3 AM. The combined log hid the error message inside a wall of success output.

Step 6: Build a Crontab Quick Reference Schedule Library

The six expressions below cover the scheduling patterns you will encounter most often. Each solves a specific timing problem, so the table maps each pattern to its intended use case.

*/5 * * * *

15 22 * * 0

0 8 * * 1-5

0 0 1 * *

0 3 */2 * *

0 3 1-10 * *

The every-5-minutes pattern suits health checks and metric collectors. The weekday-only pattern (1-5) keeps noisy jobs off weekends. The */2 step pattern distributes load across alternate days, which works well when you have multiple servers running the same task and want to stagger them manually.

For the 1-10 range pattern, note that it combines with the month field - you can narrow it further, such as 0 3 1-10 1,7 * to run only in January and July.

Step 7: Verify Your Crontab Is Working

After saving your crontab, confirm the entry stored correctly:

crontab -l

To watch cron activity in real time on systemd-based systems:

journalctl -u cron -f

On older systems using syslog, check:

grep CRON /var/log/syslog | tail -20

If a script does not execute, work through this checklist:

• Confirm the script has execute permission: chmod +x /path/to/script.sh.
• Verify the command works when run manually from a shell.
• Check that all binary paths are absolute.
• Look for typos in the five-field time expression using an online validator such as crontab-generator.org.
• Make sure stderr redirects to a log so error messages surface.
• Confirm the cron daemon runs with systemctl status cron.

Security reminder: BleepingComputer reported that the perfctl malware campaign, discovered in 2024, exploited more than 20,000 Linux misconfigurations and targeted millions of servers partly by hiding rogue cron jobs. Audit your crontab entries periodically and treat unexpected entries as an incident. The Rocke threat group has planted malicious scripts in `/etc/cron.hourly/` since at least 2018, so system-wide cron directories deserve the same scrutiny as user crontabs.