Cron Expression Generator

Cron syntax: fields and special characters

A standard cron expression has five fields: minute (0 to 59), hour (0 to 23), day of month (1 to 31), month (1 to 12 or JAN to DEC) and day of week (0 to 6 or SUN to SAT, where 0 and usually 7 are Sunday).

*, ,, - and / work everywhere. L, #, W and ? come from Quartz, Spring and AWS, and Linux crontab doesn't accept them.

• * any value, , a list (1,15), - a range (1-5 is Monday to Friday).
• / a step: */15 in minutes is 0, 15, 30 and 45, and 10-50/20 is 10, 30 and 50. Steps restart every hour or day.
• L last: the last day of the month, or 5L, the last Friday. # nth weekday: 5#2 is the second Friday. Both work here.
• W nearest weekday (15W) gets an error here. ? means no specific value and works like * in the day fields.
• Macros: @yearly and @annually (0 0 1 1 *), @monthly, @weekly, @daily and @midnight (0 0 * * *), @hourly. @reboot runs once at startup, so it has no next run. GitHub Actions takes no macros.

Common cron schedules

The generator's description, then the first run from the start time above:

• */5 * * * *: Every 5 minutes. 12:05.
• 0 * * * *: Every hour. 13:00.
• 0 */6 * * *: On the hour, every 6 hours (00, 06, 12, 18). 18:00.
• 0 8,20 * * *: At 08:00 and 20:00. 20:00.
• 0 0 * * *: At 00:00, the same as @daily. Thu, Oct 8.
• 0 9-17 * * 1-5: Every hour, between 09:00 and 17:00, Monday through Friday. 13:00.
• 0 0 * * 0: At 00:00, only on Sunday. Sun, Oct 11.
• 0 0 1 */3 *: At 00:00, on day 1 of the month, every 3 months (Jan, Apr, Jul, Oct). Fri, Jan 1, 2027.
• 0 12 * * 5#2: At 12:00, on the second Friday of the month. Fri, Oct 9.
• */30 * * * * *: Every 30 seconds (six fields). 12:00:30.
• 0 0 */2 * * isn't every other day. It hits the odd days of the month, so it runs on Oct 31 and again on Nov 1.
• Every 90 minutes needs two lines, 0 0-21/3 * * * and 30 1-22/3 * * *, because */90 in the minute field means minute 0 of every hour.

Day of month and day of week: the OR rule

When both day fields are set (neither is *), cron runs the job when either one matches. So 0 0 13 * 5 isn't Friday the 13th: the generator says "At 00:00, on day 13 of the month, and on Friday" and lists Fri, Oct 9, then Tue, Oct 13.

To require both, set one field and test the other in the command: 0 0 13 * * [ "$(date +\%u)" = 5 ] && /path/to/job. Linux crontab has no L, so month end works the same way: 0 0 28-31 * * [ "$(date -d tomorrow +\%d)" = 01 ] && /path/to/job with GNU date. Don't use 0 0 31 * *; it skips every shorter month.

Time zones and daylight saving time

Linux cron uses the server's local time zone; cronie (Fedora, RHEL) also reads a CRON_TZ= line. Kubernetes uses .spec.timeZone, or else the kube-controller-manager's zone. GitHub Actions uses UTC unless you add timezone. EventBridge Scheduler takes a zone per schedule; older EventBridge rules use UTC. On a UTC server, 0 9 * * 1-5 fires at 14:30 in Kolkata and 06:00 in São Paulo.

Runs in an hour the clocks skip or repeat differ per system. Debian's cron runs skipped jobs soon after the change and doesn't repeat them; cronie's manual pages contradict each other. EventBridge Scheduler skips the spring run and runs once in autumn. GitHub Actions moves the run to the next valid time, and so does the generator: 0 2 * * 0 in Europe/Berlin shows Sun, Mar 29, 2026, 03:00, and 30 2 * * * in Australia/Sydney shows Sun, Oct 4, 03:30.

The safe choice is a UTC schedule, or no jobs between 01:00 and 03:00 local time. The Unix Timestamp Converter shows any UTC moment in your users' zones.

Crontab, Kubernetes, GitHub Actions, AWS and Quartz

• Linux crontab: crontab -e edits, crontab -l prints, crontab -r deletes everything without asking. Lines in /etc/crontab and /etc/cron.d/ have a user name before the command, and on Debian and Ubuntu a file there with a dot in its name, like backup.cron, is ignored.
• Kubernetes CronJob: .spec.schedule takes five fields or a macro. .spec.timeZone (stable since v1.27) takes an IANA name; CRON_TZ or TZ inside the schedule fails validation.
• GitHub Actions: five fields, at most every 5 minutes, on the default branch. Runs can be late at busy times such as the top of the hour, and stop in public repositories after 60 days without activity.
• AWS EventBridge: cron(minutes hours day-of-month month day-of-week year), day of week 1 to 7 for SUN to SAT, and ? in one day field, as in cron(0 18 ? * MON-FRI *).
• Quartz and Spring: seconds first. Quartz has 6 or 7 fields (a 7th year field gets an error here), counts 1 to 7 for SUN to SAT and needs ? in one day field. Spring's @Scheduled uses 6 fields and 0 or 7 for Sunday. So 6 is Friday in Quartz and AWS but Saturday in crontab.

Why a cron job doesn't run

If the schedule looks right here but nothing happens, check these first:

• Cron doesn't load your shell profile, so node or python3 from a version manager isn't on PATH. Use full paths, or set PATH in the crontab.
• Output goes to local mail and is lost if mail isn't set up. Append >> file.log 2>&1 to see the error.
• % starts a new line in a crontab command. Write date +\%F, not date +%F.
• The last line has no newline at the end, so cron treats it as broken.
• The script isn't executable, or it needs an environment variable that only your terminal has.
• The server's time zone isn't what you assumed. Run date on the server and set Time zone here to match.

Where to put the expression

The same kind of schedule in the places you're most likely to use it. In YAML, quote the schedule: an unquoted */15 * * * * fails with unidentified alias "/15", as the YAML to JSON converter shows.

# ┌───────────── minute (0-59)
# │ ┌─────────── hour (0-23)
# │ │ ┌───────── day of month (1-31)
# │ │ │ ┌─────── month (1-12 or JAN-DEC)
# │ │ │ │ ┌───── day of week (0-6 or SUN-SAT, 0 and 7 are Sunday)
# │ │ │ │ │
# * * * * *  command
PATH=/usr/local/bin:/usr/bin:/bin
30 2 * * * /home/deploy/backup.sh >> /home/deploy/backup.log 2>&1

# /etc/cron.d/backup (no dot in the file name)
PATH=/usr/local/bin:/usr/bin:/bin
# m h dom mon dow user command
30 2 * * * deploy /home/deploy/backup.sh >> /home/deploy/backup.log 2>&1

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-report
spec:
  schedule: "30 2 * * *"
  timeZone: "Europe/Berlin"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: busybox:1.36
              command: ["sh", "-c", "date"]
          restartPolicy: OnFailure

on:
  schedule:
    - cron: "30 5 * * 1-5"
      timezone: "America/New_York"

@Scheduled(cron = "0 30 9 * * MON-FRI", zone = "Asia/Singapore")
public void sendDailyReport() {
    // 09:30 Singapore time, Monday to Friday
}