Cron Expressions — A Practical Guide with Examples & Next Run Times

What Is Cron?

Cron is a time-based job scheduler in Unix-like operating systems. It allows users to schedule jobs (commands or scripts) to run periodically at fixed times, dates, or intervals.

Cron expressions are the patterns used to define these schedules.

Cron Expression Format

A standard cron expression has 5 fields (some implementations have 6 or 7):

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

Some systems (like Quartz) use 6-7 fields:

* * * * * * *
│ │ │ │ │ │ │
│ │ │ │ │ │ └─── Year (optional)
│ │ │ │ │ └───── Day of week (0-6, where 0 = Sunday)
│ │ │ │ └─────── Month (1-12 or JAN-DEC)
│ │ │ └───────── Day of month (1-31)
│ │ └─────────── Hour (0-23)
│ └───────────── Minute (0-59)
└─────────────── Second (0-59)

Special Characters

Common Cron Examples

Every X Minutes/Hours

Specific Times

Complex Schedules

*Note: "First Monday" is tricky in standard cron. Some systems use 1-7 with 1 (Monday) to approximate.

Using FreeToolJet's Cron Parser

Our Cron Parser tool helps you understand and validate cron expressions:

Step-by-Step Guide

1. Open the Cron Parser tool
2. Enter a cron expression (e.g., 0 9 * * 1-5)
3. View the human-readable description ("At 09:00 AM, Monday through Friday")
4. See the next 10 execution times
5. Verify the expression is valid

Features

• Human-readable output: Translates cron to plain language
• Next run times: Shows when the job will next execute
• Validation: Catches syntax errors
• Multiple formats: Supports standard 5-field and Quartz 6-7 field formats
• Timezone support: Shows next runs in your local timezone

Cron in Different Systems

Linux/macOS Crontab

# Open crontab editor

# View current crontab crontab -l

# Remove crontab crontab -r `

Example crontab entries: `bash # Run backup.sh every day at 2 AM 0 2 * * * /home/user/backup.sh

# Run script every 10 minutes */10 * * * * /path/to/script.sh

# Run at reboot @reboot /path/to/script.sh `

Special Strings (Linux Crontab)

Kubernetes CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-job
spec:
  schedule: "0 2 * * *"  # Daily at 2 AM
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup-image:latest
            command: ["/bin/sh", "-c", "/backup.sh"]
          restartPolicy: OnFailure

Quartz Scheduler (Java)

Quartz uses 6-7 fields:

// Every 10 seconds

// Every day at 9 AM String cron = "0 0 9 * * ?";

// Every weekday at 9 AM String cron = "0 0 9 ? * MON-FRI"; `

Note: Quartz uses ? for "no specific value" in day-of-month or day-of-week fields.

Cron Expression Generator

If you're having trouble writing a cron expression, use our mental model:

"At X minutes past the hour..."

At 30 minutes past the hour → 30 * * * *

"Every X time units..."

Every 15 minutes → */15 * * * *
Every 2 hours → 0 */2 * * *
Every 3 days → 0 0 */3 * *

"At a specific time on specific days..."

At 9 AM on weekdays → 0 9 * * 1-5
At midnight on the 1st of every month → 0 0 1 * *

Common Pitfalls

1. Day of Week Confusion

In standard cron: - 0 = Sunday - 1-6 = Monday-Saturday - 7 = Sunday (same as 0)

In some systems: - 0 = Sunday (can also be Monday in some non-standard implementations)

Always test your cron expressions!

2. February 29th

# This will NOT run on Feb 29 (leap year)
0 0 29 2 * /path/to/script.sh

If you need a task to run on Feb 29, you'll need to check for leap year in your script.

3. Daylight Saving Time

Cron uses local time. During DST transitions: - Spring forward: A job scheduled at 2:30 AM won't run (time jumps from 2:00 to 3:00) - Fall back: A job scheduled at 1:30 AM will run twice

Workaround: Use UTC time in your cron expressions to avoid DST issues.

4. Overlapping Jobs

If a job takes longer than its interval, multiple instances might run simultaneously.

Fix: Use file locking:

#!/bin/bash
(
  flock -n 200 || exit 1
  # Your job here
) 200>/var/lock/myjob.lock

5. Environment Variables

Cron runs with a minimal environment. Scripts that work in your terminal might fail in cron.

Fix: Use absolute paths and set environment variables in the crontab:

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

Debugging Cron Jobs

1. Check Cron Logs

# Linux

# macOS tail -f /var/log/system.log | grep cron `

2. Redirect Output

# Log stdout and stderr
0 2 * * * /path/to/script.sh >> /tmp/cron.log 2>&1

3. Test Cron Environment

# Add to crontab
* * * * * env > /tmp/cron-env.log

Then check /tmp/cron-env.log to see the cron environment.

4. Run as the Cron User

Cron jobs run as the user who owns the crontab. Test with:

sudo -u username /path/to/script.sh

Cron Security Best Practices

1. Use absolute paths: Never rely on $PATH
2. Set permissions correctly: Cron scripts should not be world-writable
3. Validate input: If cron job processes external data, validate it
4. Limit environment: Don't export sensitive environment variables
5. Monitor execution: Set up alerts for failed cron jobs
6. Use least privilege: Run cron jobs as a dedicated user, not root

Alternatives to Cron

Tips for Writing Great Cron Expressions

1. Test with a short interval first: Use * * * * * (every minute) to verify your script works
2. Use descriptive comments: Add comments in your crontab explaining each job
3. Log everything: Redirect output to log files for debugging
4. Handle errors gracefully: Your script should handle failures and clean up
5. Use atomic operations: Ensure partial failures don't leave data in an inconsistent state
6. Consider timezone: Specify timezone explicitly if your server might move

Related Tools

• Cron Parser — Parse and validate cron expressions
• Timestamp Converter — Convert between timestamps and dates
• JSON Formatter — Format JSON configuration files