Mastering Crontab: 8 Common Pitfalls and Best‑Practice Solutions

Overview

crontab is the Unix/Linux scheduler that has been around since the 1970s. It works like an alarm manager: you specify a time and a command, and the daemon runs the command at the scheduled moment.

Key characteristics

Lightweight : the daemon stays in memory and uses only a few megabytes.

Highly reliable : as long as the system is up, cron fires tasks on schedule.

Simple configuration : five time fields plus a command.

User isolation : each user has its own crontab file.

Log tracking : execution is recorded in system logs.

Typical use cases

Periodic maintenance (log rotation, temporary‑file cleanup, certificate renewal).

Data processing (backups, synchronization, report generation, ETL jobs).

Monitoring and alerting (health checks, disk usage, service liveness, business metrics).

Business‑related tasks (email/SMS sending, order timeout handling, cache warming, data archiving).

Environment requirements

Operating System: CentOS 7/8, Rocky Linux 8/9, Ubuntu 20.04/22.04
cron version: cronie 1.5.x or vixie‑cron
Shell: Bash 4.x+

Make sure the cron service is installed and running:

# CentOS/RHEL/Rocky Linux
systemctl status crond
# Ubuntu/Debian
systemctl status cron

If it is not running, start and enable it:

# CentOS/RHEL/Rocky Linux
sudo systemctl start crond
sudo systemctl enable crond
# Ubuntu/Debian
sudo systemctl start cron
sudo systemctl enable cron

Preparation steps

Check time and timezone

# Show current time and timezone
date
timedatectl
# Show timezone file (Ubuntu/Debian)
cat /etc/timezone
# Show timezone link (CentOS/RHEL)
ls -l /etc/localtime
# Set timezone to Shanghai (example)
sudo timedatectl set-timezone Asia/Shanghai

Verify NTP synchronization:

# Check NTP status
timedatectl show | grep NTP
# CentOS 7+
sudo systemctl status chronyd
chronyc tracking
# Ubuntu
sudo systemctl status systemd-timesyncd

Locate crontab files and permissions

/etc/crontab            # system‑wide, requires user column
/etc/cron.d/           # directory for system‑wide tasks
/etc/cron.hourly/      # hourly scripts
/etc/cron.daily/      # daily scripts
/etc/cron.weekly/      # weekly scripts
/etc/cron.monthly/     # monthly scripts
/var/spool/cron/        # user crontabs (CentOS/RHEL)
/var/spool/cron/crontabs/ # user crontabs (Ubuntu/Debian)

Ordinary users edit their own crontab with crontab -e, which stores the file under the appropriate spool directory.

Check /etc/cron.allow and /etc/cron.deny to confirm the user is permitted to use crontab.

Crontab syntax

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

Special characters: * – any value , – list - – range / – step

Common examples:

# Every minute
* * * * * /path/to/script.sh
# Every 5 minutes
*/5 * * * * /path/to/script.sh
# Daily at 02:00
0 2 * * * /path/to/script.sh
# Weekdays at 09:00 and 18:00
0 9,18 * * 1-5 /path/to/script.sh
# First day of each quarter
0 0 1 1,4,7,10 * /path/to/script.sh

Editing crontab

# Set preferred editor (vim, nano, etc.)
export EDITOR=vim   # or nano
crontab -e

Common crontab commands:

# List tasks
crontab -l
# Edit tasks
crontab -e
# Remove all tasks (dangerous)
crontab -r
# Remove after confirmation
crontab -ri
# Import from a file
crontab /path/to/file
# Backup current crontab
crontab -l > ~/crontab_$(date +%Y%m%d).bak

Verification

Test a script in the same environment as cron:

env -i PATH=/usr/bin:/bin HOME=$HOME SHELL=/bin/bash /bin/bash /path/to/script.sh

Or add a temporary entry that writes to a log and inspect the log and system logs ( /var/log/cron on CentOS/RHEL or /var/log/syslog on Ubuntu/Debian).

Best‑practice checklist

Define SHELL, PATH, and MAILTO="" at the top of the crontab.

Use absolute paths for commands and files, or change to the script directory inside the script.

Make scripts executable ( chmod +x script.sh) and ensure required file permissions.

Guard long‑running or frequently scheduled jobs with flock to avoid overlapping executions.

Redirect both stdout and stderr to dedicated log files, e.g. > /var/log/cron/job.log 2>&1.

Configure logrotate for cron logs to prevent disk exhaustion.

If the job must run in a specific timezone, set TZ=Asia/Shanghai in the crontab (supported by some implementations) or adjust the system timezone and restart crond.

Avoid special characters such as % in commands; escape them as \% or move the logic into a script.

Common pitfalls

Missing environment variables

cron runs with a minimal PATH. Define PATH in the crontab or use full command paths.

Permission errors

Ensure the script is executable and that the user has read/write access to any files it touches. Use sudo crontab -e for root‑only tasks.

Timezone mismatches

crontab uses the system timezone. After changing the timezone, restart the cron daemon.

Unwanted email output

Set MAILTO="" or redirect output to log files to prevent mail spamming.

Concurrent executions

Wrap commands with /usr/bin/flock -xn /tmp/job.lock command to guarantee a single instance.

Special character handling

Escape % as \% or place complex pipelines inside a script.

Troubleshooting workflow

Confirm the crond service is active ( systemctl status crond or systemctl status cron).

Validate crontab syntax with crontab -l or an online validator such as crontab.guru.

Inspect system logs ( journalctl -u crond -f or grep CRON /var/log/syslog).

Run the command manually as the target user, optionally with env -i to mimic the cron environment.

Check script permissions and any required sudo rights.

Add explicit PATH and HOME definitions if the job fails.

systemd timer vs. crontab (2025 recommendation)

systemd timers provide second‑level precision, dependency handling, built‑in journald logging, retry on failure, resource limits, and persistent execution of missed runs. For new projects that need any of these features, prefer systemd timers; existing stable crontab setups can remain unchanged.

Example systemd unit and timer:

# /etc/systemd/system/backup.service
[Unit]
Description=Daily MySQL backup
After=network.target mysql.service

[Service]
Type=oneshot
User=deploy
ExecStart=/home/deploy/scripts/mysql_backup.sh
StandardOutput=journal
StandardError=journal
MemoryMax=1G
CPUQuota=50%
ProtectSystem=strict
PrivateTmp=true

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily at 02:00

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=1800

[Install]
WantedBy=timers.target

Enable and start the timer:

systemctl daemon-reload
systemctl enable --now backup.timer

Conclusion

crontab remains a simple, reliable scheduler for minute‑level tasks. By defining environment variables, using absolute paths, handling permissions, preventing overlapping runs with flock, and redirecting output to log files, most operational issues can be avoided. For workloads requiring finer granularity, dependencies, or robust failure handling, migrate to systemd timers or a dedicated workflow engine.