Cron Expression Generator

Cron Expression Generator: The Complete Guide to Cron Syntax, Job Scheduling, and Automation

Cron is the foundational task scheduling system in Unix and Linux. Named after the Greek word for time (Chronos), cron runs commands or scripts at specified recurring intervals — every minute, every hour, every day at midnight, every Monday at 9 AM, the first day of every month, or any combination thereof. First introduced by Ken Thompson in Version 7 Unix (1979) and dramatically extended by Paul Vixie in 1987 (Vixie Cron), it has become the universal language of scheduled automation on Unix systems and inspired similar scheduling syntax in cloud platforms, CI/CD systems, and container orchestrators.

A cron expression is a compact, concise string of five (or six) fields that specifies a complete schedule. Understanding cron expression syntax is essential for every developer, system administrator, and DevOps engineer who works on Unix-based systems, cloud platforms, or any modern infrastructure. This guide covers the complete cron syntax, common scheduling patterns, platform-specific extensions, debugging techniques, and alternatives for complex scheduling requirements.

The Anatomy of a Cron Expression

A standard (Unix/Vixie) cron expression consists of five space-separated fields:

┌─────────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌─────────── day of month (1 - 31)
│ │ │ ┌───────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌─────── day of week (0 - 7 or SUN-SAT, 0 and 7 are both Sunday)
│ │ │ │ │
* * * * *

Many modern platforms add a sixth field for seconds (at the beginning) or for year (at the end), but the five-field format is the universal standard.

Field Values and Ranges

• Minute: 0–59
• Hour: 0–23 (0 = midnight, 12 = noon, 23 = 11 PM)
• Day of month: 1–31
• Month: 1–12 or JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC
• Day of week: 0–7 or SUN, MON, TUE, WED, THU, FRI, SAT (both 0 and 7 = Sunday)

Special Characters

• * (asterisk): Any/every value. * * * * * = every minute
• , (comma): Multiple values. 0 9,17 * * * = at 9 AM and 5 PM
• - (hyphen): Range. 0 9-17 * * * = every hour from 9 AM to 5 PM
• / (slash): Step/interval. */5 * * * * = every 5 minutes
• ? (question mark): No specific value. Used in some implementations for day-of-month or day-of-week when the other is specified (Quartz, AWS)
• L (last): Last day of month or last weekday. L * * * in day field = last day of month (Quartz)
• W (weekday): Nearest weekday to a given day (Quartz)
• # (hash): Nth occurrence of a weekday. 2#1 = first Monday (Quartz)

Common Cron Expressions: The Essential Patterns

Every Minute, Hour, Day

• * * * * * — Every minute
• 0 * * * * — Every hour (at :00)
• 0 0 * * * — Every day at midnight
• 0 12 * * * — Every day at noon
• 0 0 1 * * — First day of every month at midnight
• 0 0 1 1 * — January 1st at midnight (annually)
• 0 0 * * 0 — Every Sunday at midnight

Business Hours and Workday Patterns

• 0 9 * * 1-5 — 9 AM Monday through Friday
• 0 9-17 * * 1-5 — Every hour from 9 AM to 5 PM, Monday–Friday
• */30 9-17 * * 1-5 — Every 30 minutes during business hours
• 0 8,12,17 * * 1-5 — 8 AM, noon, and 5 PM on weekdays
• 0 0 * * 1 — Every Monday at midnight (weekly job)
• 0 9 * * 1 — Every Monday at 9 AM
• 30 16 * * 5 — Every Friday at 4:30 PM

Interval-Based Patterns

• */5 * * * * — Every 5 minutes
• */10 * * * * — Every 10 minutes
• */15 * * * * — Every 15 minutes
• */30 * * * * — Every 30 minutes
• 0 */2 * * * — Every 2 hours
• 0 */6 * * * — Every 6 hours (midnight, 6 AM, noon, 6 PM)
• 0 */12 * * * — Every 12 hours (midnight and noon)
• 0 0 */2 * * — Every other day at midnight
• 0 0 */7 * * — Every 7 days at midnight (approximates weekly)

Monthly Patterns

• 0 0 1 * * — First of the month at midnight
• 0 0 15 * * — 15th of every month at midnight
• 0 0 1,15 * * — 1st and 15th of every month at midnight
• 0 0 28-31 * * — Last few days of every month (approximate month-end)
• 0 0 1 */3 * — First of every quarter (January, April, July, October)
• 0 0 1 1,4,7,10 * — Same as above, explicit months

Non-Standard Shortcuts

Many cron implementations support named schedule shortcuts that expand to common expressions:

• @yearly or @annually — 0 0 1 1 * (once per year, January 1 at midnight)
• @monthly — 0 0 1 * * (once per month, first day at midnight)
• @weekly — 0 0 * * 0 (once per week, Sunday midnight)
• @daily or @midnight — 0 0 * * * (once per day at midnight)
• @hourly — 0 * * * * (once per hour)
• @reboot — Run once at startup (not supported everywhere)

These shortcuts are supported by Vixie cron and most modern cron implementations, but not by Quartz Scheduler, AWS EventBridge, or other non-standard implementations.

Day-of-Month and Day-of-Week Interaction

The interaction between the day-of-month and day-of-week fields is a source of confusion. In Vixie cron (standard Unix cron):

• If both day-of-month and day-of-week are specified (not *), the job runs when either condition is true (OR logic)
• If only one is specified (the other is *), only that condition applies

Example: 0 0 1 * 1 runs at midnight on the 1st of every month AND at midnight on every Monday — not only on the 1st of the month when it's also a Monday. This behavior surprises many users who expect AND logic.

The Quartz Scheduler (used in Java applications) requires you to explicitly use ? in one of these fields when the other is specified, to make intent clear. Quartz enforces that you cannot specify both — you must put ? in one to indicate "no specific value here."

Timezone Handling in Cron

Standard Unix cron runs in the server's local timezone. This seems simple, but daylight saving time (DST) transitions create subtle problems:

• When clocks spring forward (e.g., 2:00 AM → 3:00 AM), any job scheduled at 2:30 AM is skipped entirely — that time doesn't exist.
• When clocks fall back (e.g., 2:00 AM → 1:00 AM), any job scheduled at 1:30 AM runs twice — that time exists twice.

For robust time-sensitive jobs (billing cycles, financial reports), always run cron in UTC and convert to local time in the application if needed. UTC never has DST transitions.

Some cron implementations support per-job timezone specification. Debian/Ubuntu's cron daemon and the popular supercronic support CRON_TZ or TZ environment variable per crontab:

TZ=America/New_York
0 9 * * 1-5 /path/to/morning-job.sh

Platform-Specific Cron Implementations

Linux crontab (Vixie Cron)

The most common cron implementation. Edit your personal crontab with crontab -e, list it with crontab -l, and remove it with crontab -r. System-wide crontabs are in /etc/crontab (with an additional user field) and /etc/cron.d/. Convenience directories: /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/.

Cron output is mailed to the MAILTO environment variable (defaults to the crontab owner). Set MAILTO="" to suppress emails, or redirect output explicitly: 0 * * * * /script.sh >> /var/log/job.log 2>&1

macOS launchd (plist)

macOS uses launchd as its service manager. While cron is available on macOS (crontab -e works), launchd plists are the preferred approach for periodic tasks on macOS. A launchd plist for hourly execution:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.example.hourly-job</string>
  <key>ProgramArguments</key>
  <array>
    <string>/path/to/script.sh</string>
  </array>
  <key>StartCalendarInterval</key>
  <dict>
    <key>Minute</key>
    <integer>0</integer>
  </dict>
</dict>
</plist>

GitHub Actions

GitHub Actions supports cron-scheduled workflows using the standard 5-field cron syntax:

on:
  schedule:
    - cron: '0 0 * * *'   # Daily at midnight UTC
    - cron: '0 9 * * 1-5' # 9 AM UTC on weekdays

Important notes for GitHub Actions cron:

• Always runs in UTC — there is no timezone configuration
• Minimum interval is 5 minutes (runs more frequent than 5 minutes may be throttled)
• Scheduled workflows on inactive repositories (no pushes in 60 days) may be paused by GitHub
• The ? character is NOT supported (use standard Vixie cron syntax)

AWS EventBridge (CloudWatch Events)

AWS EventBridge supports two schedule expression formats:

• Rate expressions: rate(5 minutes), rate(1 hour), rate(7 days)
• Cron expressions: A 6-field format with seconds replaced by minutes in position 1 and year added as field 6: cron(minutes hours day-of-month month day-of-week year)

AWS EventBridge cron differences from standard cron:

• The ? character is required when specifying either day-of-month or day-of-week
• The L and W characters are supported
• Minimum interval is 1 minute
• Always runs in UTC
• Year field is valid 1970–2199

Example — Daily at midnight UTC in AWS format: cron(0 0 * * ? *)

Kubernetes CronJob

Kubernetes CronJob uses standard 5-field Vixie cron syntax. Key considerations:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-cleanup
spec:
  schedule: "0 2 * * *"
  timeZone: "America/New_York"  # Kubernetes 1.27+
  concurrencyPolicy: Forbid      # Prevent concurrent runs
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cleanup
            image: my-image:latest
          restartPolicy: OnFailure

Important CronJob settings:

• concurrencyPolicy: Allow (default), Forbid (skip if previous still running), or Replace (kill previous and start new)
• startingDeadlineSeconds: How late a job can start before being considered failed (important for missed schedules)
• timeZone: Supported in Kubernetes 1.27+ — before that, runs in UTC

Quartz Scheduler (Java)

Quartz is the most widely used Java job scheduling library. It uses a 6 or 7 field cron format:

Seconds Minutes Hours DayOfMonth Month DayOfWeek [Year]
0 0 12 * * ?         // Every day at noon
0 0/5 14 * * ?       // Every 5 minutes starting at 2 PM, every day
0 0 8-10 ? * MON-FRI // 8, 9, 10 AM Monday-Friday

Quartz differences from Vixie cron:

• Seconds field added at the beginning (0–59)
• ? required in either day-of-month or day-of-week when the other is specified
• L supported (last day of month, last weekday of month)
• W supported (nearest weekday to a given day-of-month)
• # supported (Nth occurrence of weekday in month — e.g., 2#1 = first Monday)
• Day-of-month and day-of-week use AND semantics when ? is not used (differs from Vixie)

Best Practices for Cron Jobs

Idempotency

Cron jobs should be idempotent — running the same job multiple times should produce the same result as running it once. This is critical because:

• Clock adjustments or NTP sync can cause a job to run twice
• Missed schedules may be run immediately when the system recovers
• Kubernetes CronJob with concurrencyPolicy: Allow may run overlapping instances
• Distributed environments may have multiple servers with cron configured

Locking for Distributed Systems

In horizontally scaled systems with multiple servers each running cron, every server executes the same cron job simultaneously. Use distributed locks to ensure only one instance runs at a time. Common approaches:

• Database-level advisory locks (PostgreSQL's pg_try_advisory_lock)
• Redis-based distributed locks (Redlock algorithm)
• ZooKeeper or etcd ephemeral nodes
• Tools like cronsun or kronos for cron coordination

Logging and Monitoring

Every cron job should log its start time, completion time, and success/failure status. Redirect stdout and stderr to log files:

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

Monitor cron job execution with heartbeat monitoring tools like Healthchecks.io, Cronitor, or Dead Man's Snitch. These tools alert you when a cron job fails to run, which standard monitoring systems miss (they only alert on errors, not absence of execution).

Avoiding the Thundering Herd

When many cron jobs run at midnight (0 0 * * *) across many servers, they all hit shared resources simultaneously. Stagger jobs with different minutes to distribute load:

# Instead of all at midnight:
0 0 * * *   /job-one.sh
0 0 * * *   /job-two.sh

# Stagger:
0 0 * * *   /job-one.sh
15 0 * * *  /job-two.sh
30 0 * * *  /job-three.sh

Some organizations add a random jitter to job start times programmatically: sleep $((RANDOM % 300)); /job.sh delays the job up to 5 minutes randomly.

Timeout and Cleanup

Cron jobs that hang or run indefinitely block resources. Use the timeout command to enforce maximum runtime:

0 2 * * * timeout 1h /usr/local/bin/backup.sh

For Kubernetes CronJobs, set activeDeadlineSeconds on the Job spec to terminate jobs that exceed a time limit.

Permissions and Security

Cron jobs run with the permissions of the crontab owner. Avoid running cron jobs as root unless absolutely necessary — use the principle of least privilege. System crontabs in /etc/crontab have an explicit user field:

0 2 * * * backupuser /usr/local/bin/backup.sh

Restrict write access to crontab files. A writable crontab is a privilege escalation vector — anyone who can modify it can execute arbitrary code as the crontab owner.

Debugging Cron Jobs

Test Your Expression

Use a cron expression parser or online tool to verify your expression fires at the expected times. Generate the next 10 occurrences to confirm the schedule is correct. Common mistakes: off-by-one in hours (forgetting 0-based hours, writing 24 instead of 0 for midnight), wrong day-of-week number (some expect Sunday=0, others Sunday=1), and asterisk vs zero confusion.

Check the Cron Daemon Logs

# Debian/Ubuntu — check syslog
grep CRON /var/log/syslog

# RHEL/CentOS
grep CRON /var/log/cron

# journalctl (systemd)
journalctl -u cron
journalctl -u crond

# Check if cron daemon is running
systemctl status cron
service cron status

Run the Job Manually

Before relying on cron, test the job by running it manually as the cron user: sudo -u cronuser /path/to/script.sh. This catches permission issues, missing environment variables (cron has a minimal environment without ~/.bashrc or ~/.bash_profile), and missing PATH entries. The most common cron failure cause: the script works interactively because it relies on PATH settings that aren't in the minimal cron environment.

Always use full absolute paths in cron jobs, or explicitly set PATH in the crontab:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 2 * * * /usr/local/bin/backup.sh

Cron Environment Differences

Cron jobs run with a minimal environment. Variables commonly missing from cron that are present in interactive shells:

• HOME (usually set to the crontab owner's home)
• USER / LOGNAME
• SHELL (defaults to /bin/sh, not /bin/bash)
• PATH (very minimal — add explicitly)
• All terminal-specific variables (TERM, COLUMNS, ROWS)
• Anything set in .bashrc, .bash_profile, or .profile (not sourced by cron)
• SSH_AUTH_SOCK (SSH agent forwarding)

Alternatives to Cron

systemd Timers

On systemd-based Linux systems, systemd timers provide a powerful cron alternative with dependency management, logging via journald, resource controls, and better error handling. A timer unit specifies when to run a corresponding service unit:

# /etc/systemd/system/backup.timer
[Unit]
Description=Daily backup timer

[Timer]
OnCalendar=daily
Persistent=true   # Run immediately if missed
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

Persistent=true runs the job immediately if it was missed (e.g., the system was off during the scheduled time), addressing a common cron limitation. RandomizedDelaySec adds automatic jitter.

Celery Beat (Python)

For Python applications using Celery as a task queue, Celery Beat is the scheduler. It supports cron expressions and interval-based schedules and stores schedules in a database, enabling dynamic updates without redeployment. Beat runs as a separate process alongside Celery workers.

Sidekiq-Cron and Clockwork (Ruby)

Ruby applications using Sidekiq can use sidekiq-cron or sidekiq-scheduler for cron-like scheduling within the Rails/Sidekiq ecosystem. Clockwork is a simpler alternative that runs as a separate process with Ruby-based schedule definitions.

Cloud Native Schedulers

For applications already running on cloud platforms, native schedulers often make more sense than traditional cron:

• AWS EventBridge Scheduler: Managed cron/rate scheduling with guaranteed at-least-once delivery, retries, dead-letter queues, and IAM-based permissions
• Google Cloud Scheduler: Fully managed cron service with HTTP targets, Pub/Sub topics, and App Engine targets
• Azure Logic Apps: Low-code scheduled workflows with connectors to hundreds of services
• Temporal: Workflow engine with built-in cron scheduling, long-running job support, and automatic retries