Complete Cron Expression Guide: Syntax, Examples & Best Practices (2026)

A standard cron expression consists of 5 fields separated by spaces:

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

Each field accepts numeric values within its range, plus special characters that define patterns:

These characters can be combined. For example, 0 9-17/2 * * 1-5 means "at minute 0, every 2 hours from 9 AM to 5 PM, Monday through Friday."

Here are the most frequently used cron schedules with explanations:

Use our Cron Expression Generator to build any of these visually and see the next scheduled run times before deploying.

While the core 5-field syntax is universal, different platforms have variations:

Linux/Unix Crontab

The original cron daemon uses the standard 5-field format. Edit with crontab -e. Supports @reboot, @daily, @weekly, @monthly, @yearly shortcuts.

AWS EventBridge / CloudWatch

Uses a 6-field format with an additional year field: minute hour day-of-month month day-of-week year. Also supports ? (no specific value) and L (last) characters. Example: cron(0 9 ? * MON-FRI *) for weekdays at 9 AM.

Kubernetes CronJobs

Uses the standard 5-field format. Defined in YAML manifests under spec.schedule. Timezone support was added in Kubernetes 1.27+ via spec.timeZone.

GitHub Actions

Uses standard 5-field cron in the on.schedule trigger. All times are in UTC. Minimum interval is 5 minutes; GitHub may delay execution during high-load periods.

Quartz Scheduler (Java)

Uses a 6 or 7-field format with seconds and optional year: seconds minutes hours day-of-month month day-of-week [year]. Note the reversed order of the first three fields compared to Unix cron.

Cron jobs are critical infrastructure. Follow these best practices to avoid common pitfalls:

• Always specify timezone: Cron typically runs in the system timezone. If your server is in UTC but your business is in IST, jobs may run at unexpected times. Use timezone-aware schedulers or set the TZ variable.
• Avoid running at :00: Many cron jobs are scheduled at the top of the hour (0 * * * *), causing load spikes. Offset by a random minute (e.g., 17 * * * *) to distribute load.
• Use file locks: If a job takes longer than its interval, you can get overlapping runs. Use flock or a lockfile to prevent concurrent execution.
• Log output: Always redirect stdout and stderr to a log file. Cron silently discards output unless you capture it: */5 * * * * /path/to/script.sh >> /var/log/myjob.log 2>&1
• Use absolute paths: Cron runs with a minimal environment. Always use full paths for commands and scripts.
• Monitor failures: Use a dead man's switch service (like Cronitor or Healthchecks.io) to alert you when a scheduled job fails to run.
• Test with next-run preview: Before deploying, always verify the schedule by checking the next few run times. Our generator shows the next 5 runs automatically.
• Document your cron jobs: Add a comment above each cron entry explaining what it does and who owns it.

Cron jobs fail silently more often than you'd expect. Here are the most common issues and fixes:

Job Not Running At All

• Cron daemon not running: Check with systemctl status cron (systemd) or service cron status.
• Syntax error: Even one extra space or missing field breaks the entire crontab. Validate with our parser before deploying.
• Wrong user: System-wide cron (/etc/crontab) has a 6th user field. User crontabs (crontab -e) do not.

Job Runs But Fails

• Missing environment variables: Cron runs with a minimal PATH. Either set PATH at the top of your crontab or use absolute paths.
• Permission denied: Ensure the script is executable (chmod +x) and the cron user has permission to access all required files.
• Working directory: Cron doesn't set a working directory. Use cd /path/to/project && at the start of your command.

Job Runs at Wrong Time

• Timezone mismatch: Check system timezone with timedatectl. Server UTC vs local time is the #1 cause of "wrong time" issues.
• DST changes: During daylight saving transitions, jobs scheduled between 2-3 AM may run twice, once, or not at all depending on the system.