Cron Job Examples for Common Tasks (Copy-Paste Ready)

Need a cron job but don’t want to memorize the syntax? This guide provides copy-paste ready examples for the most common scheduling tasks, from daily backups to monthly reports.

The Quick Answer

Here are the 5 most common cron schedules you’ll use:

• Every day at 2 AM: 0 2 * * *
• Every hour: 0 * * * *
• Every Monday at 9 AM: 0 9 * * 1
• First day of month at midnight: 0 0 1 * *
• Every 15 minutes: */15 * * * *

Cron Syntax Explained

Cron uses a 5-field format representing when to run your command:

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

Special characters:

• * = Every value (every minute, every hour, etc.)
• , = Multiple values (1,15 = 1st and 15th)
• - = Range (1-5 means 1 through 5)
• / = Step values (*/10 means every 10 units)

Reference Chart: Common Schedules

Schedule	Cron Expression	When It Runs
Every minute	* * * * *	Every minute of every day
Every 5 minutes	*/5 * * * *	At 0, 5, 10, 15… minutes
Every 15 minutes	*/15 * * * *	At 0, 15, 30, 45 minutes
Every 30 minutes	*/30 * * * *	At 0 and 30 minutes
Every hour	0 * * * *	On the hour, every hour
Every 2 hours	0 */2 * * *	At 0:00, 2:00, 4:00, etc.
Every day at midnight	0 0 * * *	12:00 AM daily
Every day at 2 AM	0 2 * * *	2:00 AM daily
Every day at 9:30 AM	30 9 * * *	9:30 AM daily
Every weekday at 9 AM	0 9 * * 1-5	Monday-Friday at 9:00 AM
Every Sunday at 3 AM	0 3 * * 0	Sunday at 3:00 AM
Every Monday at 9 AM	0 9 * * 1	Monday at 9:00 AM
First day of month	0 0 1 * *	Midnight on the 1st
Last day of month	0 0 28-31 * *	Runs on 28-31, only executes if day exists
Every quarter (Jan/Apr/Jul/Oct)	0 0 1 1,4,7,10 *	First day of quarter months
Twice daily (9 AM, 6 PM)	0 9,18 * * *	9:00 AM and 6:00 PM
Business hours (9-5)	0 9-17 * * 1-5	Every hour, weekdays 9 AM-5 PM

Real-World Examples

1. Database Backups

Daily backup at 2 AM:

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

Hourly incremental backups during business hours:

0 9-17 * * 1-5 /usr/local/bin/incremental-backup.sh

Weekly full backup on Sunday night:

0 1 * * 0 /usr/local/bin/full-backup.sh && aws s3 sync /backups s3://my-backup-bucket

2. System Maintenance

Clear temp files every day at 3 AM:

0 3 * * * find /tmp -type f -mtime +7 -delete

Restart service every Sunday at 4 AM:

0 4 * * 0 systemctl restart my-service

Check disk space every hour and alert if low:

0 * * * * /usr/local/bin/check-disk-space.sh

3. Reports and Analytics

Daily sales report at 6 AM:

0 6 * * * /usr/local/bin/generate-sales-report.py --yesterday | mail -s "Daily Sales Report" team@company.com

Weekly summary every Monday at 8 AM:

0 8 * * 1 /usr/local/bin/weekly-summary.sh

Monthly report on the 1st at 9 AM:

0 9 1 * * /usr/local/bin/monthly-analytics.py --last-month

4. Monitoring and Health Checks

Check website every 5 minutes:

*/5 * * * * curl -f https://mysite.com/health || echo "Site down!" | mail -s "ALERT" admin@company.com

Monitor CPU/memory every 10 minutes:

*/10 * * * * /usr/local/bin/monitor-resources.sh

SSL certificate expiry check daily:

0 8 * * * /usr/local/bin/check-ssl-expiry.sh

5. Data Processing

Process queue every minute:

* * * * * /usr/local/bin/process-queue.py

ETL job every 6 hours:

0 */6 * * * /usr/local/bin/etl-pipeline.sh

Sync data with external API every 30 minutes:

*/30 * * * * /usr/local/bin/sync-external-data.py

6. Content and Social Media

Publish scheduled posts every 15 minutes:

*/15 * * * * /usr/local/bin/publish-scheduled-posts.sh

Generate sitemap daily at midnight:

0 0 * * * cd /var/www/mysite && php artisan sitemap:generate

Clear cache every 4 hours:

0 */4 * * * redis-cli FLUSHDB

Pro Tips

1. Always Log Output

Redirect both stdout and stderr to a log file to debug issues:

0 2 * * * /path/to/script.sh >> /var/log/cron.log 2>&1

The 2>&1 ensures error messages are also captured.

2. Use Absolute Paths

Cron runs with a limited PATH. Always use full paths:

# BAD - may not find python
0 2 * * * python script.py

# GOOD - explicit path
0 2 * * * /usr/bin/python3 /home/user/scripts/script.py

3. Set Environment Variables

Add variables at the top of your crontab:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=admin@company.com

0 2 * * * /path/to/backup.sh

4. Test Before Scheduling

Run your script manually first:

# Test the exact command
/usr/bin/python3 /home/user/scripts/backup.py

# Check exit code
echo $?  # Should be 0 for success

5. Use Locking for Long-Running Jobs

Prevent overlapping executions with flock:

* * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/script.sh

The -n flag ensures the script won’t run if the lock file exists.

6. Email Notifications

Set MAILTO to receive output via email:

MAILTO=admin@example.com
0 2 * * * /path/to/backup.sh

Or suppress emails entirely:

0 2 * * * /path/to/script.sh > /dev/null 2>&1

7. Use a Wrapper Script

For complex jobs, use a wrapper that handles logging, error checking, and notifications:

#!/bin/bash
# /usr/local/bin/backup-wrapper.sh

LOG_FILE="/var/log/backup.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

echo "[$DATE] Starting backup..." >> $LOG_FILE

if /usr/local/bin/backup.sh; then
    echo "[$DATE] Backup completed successfully" >> $LOG_FILE
else
    echo "[$DATE] Backup failed!" >> $LOG_FILE
    echo "Backup failed at $DATE" | mail -s "BACKUP FAILURE" admin@company.com
    exit 1
fi

Then schedule the wrapper:

0 2 * * * /usr/local/bin/backup-wrapper.sh

Common Mistakes

1. Timezone Confusion

Problem: Cron uses the system timezone, which may differ from your local timezone.

Solution: Check your server timezone:

timedatectl  # Linux
date         # Show current time

Or use UTC and adjust your cron times accordingly.

2. PATH Issues

Problem: Script works manually but fails in cron due to missing binaries.

Solution: Set PATH in crontab or use absolute paths:

PATH=/usr/local/bin:/usr/bin:/bin
0 2 * * * python3 /path/to/script.py

3. Forgetting to Make Scripts Executable

Problem: Permission denied errors.

Solution:

chmod +x /path/to/script.sh

4. No Output Capture

Problem: Job fails silently with no way to debug.

Solution: Always redirect output:

0 2 * * * /path/to/script.sh >> /var/log/script.log 2>&1

5. Using % Without Escaping

Problem: The % character has special meaning in cron (newline).

Solution: Escape it with backslash:

0 2 * * * /usr/bin/date +\%Y-\%m-\%d >> /var/log/date.log

Or put the command in a script file instead.

6. Not Testing Edge Cases

Problem: “Last day of month” schedules fail in short months.

Solution: Use a script to calculate the actual last day:

0 0 28-31 * * [ $(date -d tomorrow +\%d) -eq 1 ] && /path/to/script.sh

This checks if tomorrow is the 1st. If so, today is the last day.

7. Ignoring Exit Codes

Problem: Cron continues even if previous commands fail.

Solution: Use && to chain dependent commands:

0 2 * * * /usr/local/bin/backup.sh && /usr/local/bin/upload-to-s3.sh

The second command will only run if the first succeeds.

Editing Your Crontab

View current crontab:

crontab -l

Edit crontab:

crontab -e

Remove all cron jobs:

crontab -r

Edit another user’s crontab (as root):

crontab -u username -e

Quick Validation Checklist

Before saving your cron job, verify:

• ✓ Absolute paths used for commands and scripts
• ✓ Script has execute permissions (chmod +x)
• ✓ Output is redirected to a log file
• ✓ Script tested manually and returns exit code 0
• ✓ Environment variables set if needed
• ✓ MAILTO configured for critical jobs
• ✓ Locking mechanism for long-running tasks
• ✓ Timezone is correct for your schedule

Frequently Asked Questions

What does the asterisk mean in cron expressions?

The asterisk is a wildcard meaning “every” value for that field. For example, * * * * * runs every minute, while 0 * * * * runs at minute 0 of every hour (hourly). In the expression 30 9 * * 1, the asterisks mean “every day of month” and “every month,” so it runs at 9:30 AM every Monday regardless of date.

How do I test a cron expression before deploying?

Use a cron expression validator or our cron generator tool which shows the next 5 scheduled run times. Before scheduling, test the actual script manually using the exact command you’ll put in crontab, then check the exit code with echo $? (should be 0 for success). Never deploy untested cron jobs to production because they fail silently and can go unnoticed for days.

Why is my cron job not running even though the syntax is correct?

The most common culprits are PATH issues (cron has a limited PATH, so use absolute paths like /usr/bin/python3), missing execute permissions (chmod +x script.sh), timezone confusion (cron uses system timezone, not your local one), or the script failing but you can’t see errors because output isn’t redirected to a log file. Always add >> /var/log/script.log 2>&1 to capture both stdout and stderr.

Can I run a cron job every 30 seconds or more frequently than once per minute?

No, cron’s minimum granularity is 1 minute. For sub-minute intervals, you have two options: use * * * * * /path/script.sh && sleep 30 && /path/script.sh to run twice per minute, or use a proper job scheduler like systemd timers (Linux) or a process supervisor that supports second-level intervals. For production workloads needing sub-minute precision, consider a dedicated task queue system.

Build Your Own Cron Expression

Need a custom schedule? Use our interactive cron generator to build and validate your cron expression with a visual calendar preview. No more guessing whether 0 9 * * 1-5 means weekdays at 9 AM (it does).