What is a cron job in Linux

Sébastien Puyet

Sébastien Puyet

— 9 min read
What is a cron job in Linux

Cron jobs are automated tasks that run at scheduled intervals on Linux systems, powered by the cron daemon - a time-based job scheduler that operates continuously in the background. Think of cron as your system's personal assistant that never sleeps, executing commands, scripts, and maintenance tasks exactly when you need them, whether that's every minute, daily at 3 AM, or on the last Friday of each month.

System administrators rely on cron jobs for critical automation: backing up databases at midnight when traffic is low, rotating log files weekly to prevent disk space issues, monitoring system health hourly, and performing security updates during maintenance windows. This automation ensures consistent execution regardless of whether anyone is logged into the system, making it essential for maintaining high availability and operational efficiency.

What Are Cron Jobs and Why Use Them?

The cron system consists of three main components: the cron daemon (crond), which runs continuously and checks for scheduled tasks; crontab files, which store the scheduling information; and the actual cron jobs: the commands or scripts that get executed.

E-commerce sites use cron jobs to generate daily sales reports, clean up abandoned shopping carts, and synchronize inventory with suppliers. Web applications leverage cron for sending scheduled emails, processing queued tasks, and performing database maintenance. System administrators depend on cron for automated backups, security scans, certificate renewals, and monitoring disk usage. Cron jobs are everywhere.

The key benefits include reliability, cron jobs run consistently without human intervention; resource efficiency, tasks execute during off-peak hours when system resources are available; and operational continuity - critical maintenance happens automatically, reducing the risk of forgotten manual tasks.

However, cron isn't suitable for every scenario. Avoid using cron for high-frequency tasks (more than once per minute), interactive processes requiring user input, or tasks that need real-time event-driven execution. For these cases, consider alternatives like systemd timers, event-driven systems, or dedicated job queues.

Prerequisites and System Setup Verification

Before creating cron jobs, verify that the cron daemon is running on your system. Most Linux distributions start cron automatically, but it's worth checking:

# Check cron daemon status
sudo systemctl status cron

# On some systems, it might be called crond
sudo systemctl status crond

If cron isn't running, start and enable it:

sudo systemctl start cron
sudo systemctl enable cron

Understanding the difference between system and user crontabs is crucial. User crontabs (accessed via crontab -e) run with the permissions of the user who created them. System crontabs (in /etc/crontab and /etc/cron.d/) can specify which user should run each job and typically handle system-wide maintenance tasks.

Cron jobs run with a minimal environment, meaning the PATH variable and other environment settings differ from your interactive shell. This limitation causes many cron job failures, so always use absolute paths for commands or explicitly set environment variables in your crontab.

Understanding Cron Job Syntax and Timing

Cron job scheduling uses a five-field format that precisely defines when tasks should run:

* * * * * command-to-execute
│ │ │ │ │
│ │ │ │ └─── Day of week (0-7, Sunday = 0 or 7)
│ │ │ └───── Month (1-12)
│ │ └─────── Day of month (1-31)
│ └───────── Hour (0-23)
└─────────── Minute (0-59)

The asterisk (*) means "any value" for that field. For example, 30 2 * * * runs at 2:30 AM every day, while 0 */4 * * * runs every 4 hours at the top of the hour.

Special operators provide flexibility:

  • Comma (,) separates multiple values: 0 9,17 * * * runs at 9 AM and 5 PM
  • Hyphen (-) defines ranges: 0 9-17 * * * runs hourly from 9 AM to 5 PM
  • Forward slash (/) specifies intervals: */15 * * * * runs every 15 minutes

Special keywords simplify common schedules:

  • @yearly or @annually - Run once per year (0 0 1 1 *)
  • @monthly - Run once per month (0 0 1 * *)
  • @weekly - Run once per week (0 0 * * 0)
  • @daily or @midnight - Run once per day (0 0 * * *)
  • @hourly - Run once per hour (0 * * * *)
  • @reboot - Run at system startup

Complex scheduling examples demonstrate advanced patterns:

  • Business hours only: 0 9-17 * * 1-5 (hourly, weekdays 9 AM to 5 PM)
  • Every 15 minutes during peak hours: */15 9-17 * * 1-5
  • Last day of month: 0 2 28-31 * * (runs daily from 28th-31st, but script checks if tomorrow is next month)

Creating Your First Cron Job

Start by opening your user's crontab for editing:

crontab -e

If this is your first time, the system will prompt you to choose an editor. Select nano for simplicity or vim if you're comfortable with it. You can change this later by setting the EDITOR environment variable.

Let's create a simple cron job that writes the current date to a file every minute for testing:

# Test cron job - runs every minute
* * * * * /bin/date >> /home/username/cron-test.log

Replace "username" with your actual username. Save and exit the editor. The system will confirm that the crontab has been installed.

Verify your cron job is scheduled:

crontab -l

Wait a couple of minutes, then check if the job is working:

cat /home/username/cron-test.log

You should see timestamp entries appearing every minute. This confirms that cron is working and can execute basic commands. Once verified, remove this test job by editing your crontab again and deleting the line.

Understanding output handling is crucial. By default, cron emails any output to the job owner. To redirect output to a file instead, use redirection operators. To suppress all output, redirect to /dev/null:

# Save output and errors to file
* * * * * /path/to/script.sh >> /var/log/myscript.log 2>&1

# Suppress all output
* * * * * /path/to/script.sh > /dev/null 2>&1

Practical Cron Job Examples

Daily System Backup

This example creates a compressed backup of important directories every day at 2 AM:

# Daily backup at 2 AM
0 2 * * * /usr/bin/tar -czf /backup/system-$(date +\%Y\%m\%d).tar.gz /etc /home /var/www

Note the escaped percentage signs (\%) - cron treats % as newline characters, so they must be escaped in the crontab.

Weekly Log Cleanup

Remove log files older than 30 days every Sunday at 3 AM:

# Weekly log cleanup
0 3 * * 0 /usr/bin/find /var/log -name "*.log" -mtime +30 -delete

Hourly Disk Space Monitoring

Check disk usage every hour and alert if usage exceeds 90%:

# Disk space monitoring
0 * * * * /home/admin/scripts/check-disk-space.sh

Here's the corresponding script (/home/admin/scripts/check-disk-space.sh):

#!/bin/bash
THRESHOLD=90
USAGE=$(df / | awk 'NR==2 {print $5}' | sed 's/%//')

if [ $USAGE -gt $THRESHOLD ]; then
    echo "WARNING: Disk usage is ${USAGE}% on $(hostname)" | \
    mail -s "Disk Space Alert" admin@company.com
fi

Database Backup with Rotation

Backup MySQL database daily and keep only the last 7 days:

# Database backup with rotation
30 1 * * * /home/admin/scripts/mysql-backup.sh

The backup script:

#!/bin/bash
BACKUP_DIR="/backup/mysql"
DATE=$(date +%Y%m%d)
DB_NAME="production"

# Create backup
mysqldump -u backup_user -p'password' $DB_NAME > $BACKUP_DIR/db-$DATE.sql

# Compress backup
gzip $BACKUP_DIR/db-$DATE.sql

# Remove backups older than 7 days
find $BACKUP_DIR -name "db-*.sql.gz" -mtime +7 -delete

System Health Report

Generate a comprehensive system report every morning at 6 AM:

# Daily system health report
0 6 * * * /home/admin/scripts/system-health.sh | mail -s "Daily System Report" admin@company.com

Environment Variables and Script Execution

Cron jobs fail frequently due to environment differences. When you run commands interactively, your shell loads environment variables from various configuration files. Cron jobs run with a minimal environment, typically only setting HOME, LOGNAME, and SHELL variables.

Set environment variables at the top of your crontab:

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
SHELL=/bin/bash
HOME=/home/username

# Your cron jobs follow
0 2 * * * /home/username/scripts/backup.sh

For complex environments, source your profile in scripts:

#!/bin/bash
source /home/username/.bashrc
# Rest of your script

Always use absolute paths for executables and files. Instead of python script.py, use /usr/bin/python3 /home/username/scripts/script.py.

Make scripts executable and test them manually before scheduling:

chmod +x /home/username/scripts/backup.sh
/home/username/scripts/backup.sh

Managing Cron Job Output and Notifications

By default, cron emails output to the job owner. Configure email notifications by setting the MAILTO variable:

MAILTO=admin@company.com,ops@company.com

# Jobs will email output to both addresses
0 2 * * * /home/admin/backup.sh

For systems without mail configuration, redirect output to log files:

# Separate logs for output and errors
0 2 * * * /home/admin/backup.sh >> /var/log/backup.log 2>> /var/log/backup-errors.log

# Combined logging
0 2 * * * /home/admin/backup.sh >> /var/log/backup.log 2>&1

Implement custom notifications using scripts that only alert on failures:

#!/bin/bash
LOG_FILE="/var/log/backup.log"
ERROR_FILE="/var/log/backup-error.log"

# Run backup command
if ! /usr/bin/rsync -av /home/ /backup/home/ >> $LOG_FILE 2>> $ERROR_FILE; then
    echo "Backup failed on $(hostname) at $(date)" | \
    mail -s "BACKUP FAILURE" admin@company.com
fi

Rotate log files to prevent disk space issues:

# Weekly log rotation
0 0 * * 0 /usr/sbin/logrotate /etc/logrotate.d/custom-cron-logs

System-Wide Cron Jobs and Advanced Configuration

System-wide cron jobs offer more flexibility for multi-user environments. The system crontab (/etc/crontab) includes an additional user field:

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Create application-specific cron jobs in /etc/cron.d/:

# File: /etc/cron.d/webapp-maintenance
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Database cleanup every night
0 2 * * * webapp /opt/webapp/scripts/cleanup.sh

# Log rotation weekly
0 1 * * 0 webapp /opt/webapp/scripts/rotate-logs.sh

Use system cron directories for simple scripts:

  • /etc/cron.hourly/ - Scripts run every hour
  • /etc/cron.daily/ - Scripts run daily
  • /etc/cron.weekly/ - Scripts run weekly
  • /etc/cron.monthly/ - Scripts run monthly

Scripts in these directories must be executable and should not have file extensions:

sudo cp backup-script.sh /etc/cron.daily/backup-script
sudo chmod +x /etc/cron.daily/backup-script

Troubleshooting Cron Jobs

When cron jobs fail, follow this systematic debugging approach:

Step 1: Verify cron daemon is running

sudo systemctl status cron
# Check recent cron activity
sudo journalctl -u cron -f

Step 2: Check cron logs

# Common log locations
sudo tail -f /var/log/cron
sudo tail -f /var/log/syslog | grep CRON
sudo journalctl -u cron --since "1 hour ago"

Step 3: Verify crontab syntax

# List current crontab
crontab -l

# Test cron expressions online or with tools
# Ensure no syntax errors in timing fields

Step 4: Test script manually

Run your script with the same environment cron uses:

# Simulate cron environment
sudo -u username env -i HOME=/home/username PATH=/usr/bin:/bin /home/username/script.sh

Step 5: Enable verbose logging

Temporarily modify your cron job to capture detailed output:

# Add debugging to cron job
* * * * * /bin/bash -x /home/username/script.sh >> /tmp/cron-debug.log 2>&1

Common Issues and Solutions:

  • Permission denied: Check file permissions and ownership
  • Command not found: Use absolute paths or set PATH variable
  • Script runs manually but not via cron: Environment variable differences
  • No output or logging: Add explicit logging to your scripts

Create a troubleshooting checklist:

#!/bin/bash
# Cron job debugging script
echo "=== Cron Debug Info ==="
echo "Date: $(date)"
echo "User: $(whoami)"
echo "PATH: $PATH"
echo "HOME: $HOME"
echo "Working directory: $(pwd)"
echo "Environment:"
env | sort
echo "======================="

Security Best Practices

Implement security measures to protect your cron jobs and system:

Use principle of least privilege: Run cron jobs with minimal required permissions. Create dedicated service accounts for specific tasks:

# Create backup user with limited permissions
sudo useradd -r -s /bin/bash backup-user
sudo usermod -aG backup backup-user

Secure script storage: Store scripts in protected directories with appropriate permissions:

# Secure script permissions
chmod 750 /home/admin/scripts/
chmod 640 /home/admin/scripts/*.sh
chown admin:admin /home/admin/scripts/*

Avoid sensitive data in crontabs: Never put passwords or API keys directly in crontab entries. Use configuration files or environment variables:

# Bad: password visible in crontab
0 2 * * * mysqldump -u user -p'secret123' database

# Good: use configuration file
0 2 * * * /home/admin/scripts/backup.sh

Validate PATH security: Ensure your PATH doesn't include world-writable directories where attackers could place malicious executables:

# Check directory permissions in PATH
echo $PATH | tr ':' '\n' | xargs ls -ld

Monitor crontab changes: Set up alerts for crontab modifications:

# Monitor crontab files
sudo auditctl -w /var/spool/cron/crontabs -p wa -k crontab_changes

Monitoring and Performance Optimization

Implement monitoring to ensure cron jobs run successfully and efficiently:

Create health checks: Build monitoring into your scripts:

#!/bin/bash
SCRIPT_NAME="backup"
LOG_FILE="/var/log/${SCRIPT_NAME}.log"
LOCK_FILE="/tmp/${SCRIPT_NAME}.lock"

# Prevent overlapping executions
if [ -f "$LOCK_FILE" ]; then
    echo "$(date): Script already running" >> $LOG_FILE
    exit 1
fi

echo $$ > $LOCK_FILE

# Your script logic here
if backup_function; then
    echo "$(date): Backup completed successfully" >> $LOG_FILE
else
    echo "$(date): Backup failed" >> $LOG_FILE
    # Send alert
fi

rm -f $LOCK_FILE

Optimize resource usage: Stagger job execution to avoid system overload:

# Instead of all jobs at midnight
0 0 * * * /scripts/job1.sh
5 0 * * * /scripts/job2.sh
10 0 * * * /scripts/job3.sh

# Use nice/ionice for resource-intensive jobs
0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /scripts/heavy-backup.sh

Set up centralized monitoring: Use tools like Nagios, Zabbix, or custom solutions to monitor cron job success:

# Simple success/failure tracking
#!/bin/bash
JOB_NAME="daily-backup"
STATUS_FILE="/var/lib/cron-status/${JOB_NAME}"

if run_backup_command; then
    echo "SUCCESS $(date)" > $STATUS_FILE
    exit 0
else
    echo "FAILURE $(date)" > $STATUS_FILE
    exit 1
fi

Quick Reference and Next Steps

Essential Commands:

  • crontab -e - Edit user crontab
  • crontab -l - List current cron jobs
  • crontab -r - Remove all cron jobs
  • sudo crontab -u username -e - Edit another user's crontab

Common Time Patterns:

  • Every minute: * * * * *
  • Every 15 minutes: */15 * * * *
  • Daily at 2:30 AM: 30 2 * * *
  • Weekly on Sunday at midnight: 0 0 * * 0
  • Monthly on the 1st at 3 AM: 0 3 1 * *
  • Weekdays at 9 AM: 0 9 * * 1-5

Emergency Procedures:

# Stop all cron jobs temporarily
sudo systemctl stop cron

# Kill specific runaway process
sudo pkill -f "script-name"

# Remove problematic cron job quickly
crontab -e  # Delete the problematic line

Now that you understand cron job fundamentals, consider exploring advanced scheduling tools like systemd timers for more complex requirements, or integrating cron job monitoring with your existing infrastructure monitoring solutions. Practice creating and testing cron jobs in a development environment before deploying to production systems.

Remember that reliable automation requires careful planning, thorough testing, and ongoing monitoring. Start with simple jobs and gradually build more complex automation as you gain confidence with cron's capabilities and limitations.

Read more