Cron Job Setup

You are a backend developer setting up automated scheduled tasks. The user wants to create and configure cron jobs to run tasks at specific intervals.

What to check first

• Run crontab -l to see existing cron jobs on the system
• Verify the cron daemon is running: sudo systemctl status cron (Linux) or launchctl list | grep cron (macOS)
• Check /var/log/syslog or /var/log/system.log for cron execution logs

Steps

1. Open the crontab editor with crontab -e to create a new job for the current user
2. Understand the cron syntax: minute hour day month weekday command (5 fields, 0-indexed for day of week where 0=Sunday)
3. Use */5 for "every 5 minutes", 0 */2 for "every 2 hours", or 0 0 * * * for "daily at midnight"
4. Write the absolute path to your script or binary — relative paths often fail in cron context
5. Redirect output explicitly: append >> /var/log/cron-job.log 2>&1 to capture stdout and stderr
6. Test with a simple command like * * * * * date >> /tmp/cron-test.log to verify cron is executing
7. For system-wide jobs, edit /etc/crontab or place scripts in /etc/cron.d/ with a username field added
8. Use crontab -r to remove all jobs, or edit with crontab -e and delete individual lines

Code

#!/bin/bash
# Example: Daily backup script to be called by cron

BACKUP_DIR="/backups"
DB_NAME="myapp_db"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
LOG_FILE="/var/log/backup.log"

# Create backup directory if it doesn't exist
mkdir -p "$BACKUP_DIR"

# Perform database dump
pg_dump "$DB_NAME" > "$BACKUP_DIR/db_backup_$TIMESTAMP.sql" 2>> "$LOG_FILE"

if [ $? -eq 0 ]; then
  echo "[$(date +'%Y-%m-%d %H:%M:%S')] Backup successful: db_backup_$TIMESTAMP.sql" >> "$LOG_FILE"
else
  echo "[$(date +'%Y-%m-%d %H:%M:%S')] Backup failed for $DB_NAME" >> "$LOG_FILE"
  exit 1
fi

# Compress the backup
gzip "$BACKUP_DIR/db_backup_$TIMESTAMP.sql"

# Clean up backups older than 7 days
find "$BACKUP_DIR" -name "*.sql.gz" -type f -mtime +7 -delete

# Optional: Send to remote storage
# aws s3 cp "$BACKUP_

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change