Cron Expression Guide

Cron is the time-based job scheduler built into Unix-like operating systems. It lets you schedule commands or scripts to run at specific times — every minute, every Tuesday at 3 AM, or the first day of every quarter. Despite its power, the syntax can be cryptic for beginners and even experienced developers find themselves checking references regularly.

This guide covers everything you need to know about cron expressions: the five standard fields, special strings, real-world schedule examples, troubleshooting tips, and timezone considerations. Whether you're writing a crontab file or configuring a cloud scheduler, this reference has you covered.

1. Cron Syntax Fundamentals

A standard cron expression has five fields, separated by spaces:

Important note on Day of Week: Both 0 and 7 represent Sunday. Most systems use 0 for Sunday, 1 for Monday, through 6 for Saturday. Some systems (like Quartz) use 1 for Sunday and 2-7 for Monday-Saturday — always check your implementation.

Special Characters

2. Special Strings

Many cron implementations support shorthand strings for common schedules. These are especially useful in cloud schedulers (AWS EventBridge, Google Cloud Scheduler) and systemd timers.

3. Common Schedule Examples

Here are real-world cron expressions organized by use case. Copy-paste these into your crontab and adjust as needed.

Every Minute / High Frequency

Hourly / Every N Hours

Daily Schedules

Weekly / Weekday Schedules

Monthly / Advanced Schedules

4. Crontab Quick Reference

The crontab command manages your cron jobs. Each user has their own crontab file.

A crontab entry has this format:

# ┌───────────── minute (0-59)
# │ ┌───────────── hour (0-23)
# │ │ ┌───────────── day of month (1-31)
# │ │ │ ┌───────────── month (1-12)
# │ │ │ │ ┌───────────── day of week (0-7, 0 or 7 = Sunday)
# │ │ │ │ │
# * * * * *  command_to_run

# Example: backup database every day at 2:30 AM
30 2 * * * /usr/local/bin/backup.sh

# Example: send a report every Monday at 9 AM
0 9 * * 1 /usr/local/bin/send-report.sh

5. Timezone Considerations

Standard Unix cron uses the system timezone. This is one of the most common sources of confusion — especially when your server is in UTC and you expect a local time.

• Unix cronreads the system's timezone (set via /etc/timezone or the TZ environment variable). You can set TZ=America/New_York at the top of your crontab to run jobs in a specific timezone.
• Systemd timers use the system timezone. Check with timedatectl.
• AWS EventBridge supports setting a timezone per rule. The default is UTC.
• Google Cloud Scheduler requires you to specify the timezone explicitly (e.g., America/New_York).
• Kubernetes CronJobs run in the timezone of the kube-controller-manager. As of Kubernetes 1.27+, you can set spec.timeZone in the CronJob spec.

6. Troubleshooting

Cron jobs can fail silently. Here are the most common issues and how to fix them.

Debugging Checklist

1. Verify the cron daemon is running: systemctl status cron or ps aux | grep cron
2. Check system timezone: timedatectl or date +%Z
3. List your crontab: crontab -l
4. Add a simple test job that writes to a file every minute
5. Check cron logs: grep cron /var/log/syslog or /var/log/cron
6. Ensure the script is executable and uses absolute paths
7. Redirect stdout and stderr to a log file for debugging

7. Cron in the Cloud

Cloud-native schedulers use cron-like syntax with some differences. Here's how each platform handles it:

8. Alternative Notations

Some systems extend cron syntax with additional fields or alternative formats:

6-Field (Quartz) Format

Quartz schedulers (common in Java / Spring Boot) add a seconds field at the beginning and an optional year field at the end:

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

# Example: run at 10:15 AM every day
0 15 10 * * ?

Common Mistakes & How to Avoid Them

Most cron incidents aren't syntax errors — they're environment mismatches between your shell and cron's minimal runtime. These are the five that bite developers most often in production.

• Assuming cron uses your local timezone. Cron uses the system timezone, not your shell's TZ or locale. Verify with timedatectl. To force a zone, put CRON_TZ=America/New_York at the top of your crontab (Vixie cron), or schedule in UTC and convert.
• Using relative paths. Cron's default PATH is minimal (/usr/bin:/bin), so node, python3, and project binaries often aren't found. Use absolute paths to both the interpreter and the script, or set PATH=/usr/local/bin:/usr/bin:/bin at the top of the crontab.
• Forgetting to escape %. In a crontab, % is translated to a newline. A command like date +%Y-%m-%d silently breaks — write it as date +\%Y-\%m-\%d.
• Combining day-of-month and day-of-week. The two fields are OR'd, not AND'd: 0 0 1 * 1 runs on the 1st of the month and every Monday — twice as often as intended. Use ? in Quartz-style schedulers, or split into two separate jobs.
• Scripts that aren't executable. If your script lacks chmod +x or a valid shebang, cron fails silently — no email, no log entry. Always run chmod +x /path/to/script.sh and test the script manually before wiring it into cron.