Cron Expression Generator & Parser

The complete guide to cron expressions, scheduling syntax, and real-world gotchas

Cron is the oldest scheduler still in production. The first version shipped with Unix V7 in 1979, written by Brian Kernighan. Forty-seven years later, the same five-field syntax drives Kubernetes CronJobs, GitHub Actions, AWS EventBridge, Jenkins, Airflow, GitLab pipelines, Vercel cron, and every cloud function platform in production. Knowing how to read and write cron correctly is a baseline DevOps skill — and it is also the most common source of "why didn't my job run?" tickets. This guide walks through the syntax, the dialect differences (POSIX vs Quartz vs AWS vs Kubernetes), the timezone rules that bite teams, and the patterns I rely on after a decade of running cron-driven systems.

The five fields, decoded

A standard cron expression is five space-separated fields. Read left to right:

The wildcards and operators each have a precise meaning:

Cron dialects — they are not all the same

Half the bugs I have seen with cron come from running an expression that was valid in one system but not the one actually executing it. Here is the truth table:

The OR-vs-AND day rule that surprises everyone

Standard POSIX cron has a non-obvious rule: when both day-of-month and day-of-week are specific (not *), the job fires on days matching either field — the operators are OR'd. When only one of them is specific, normal AND semantics apply. The classic gotcha:

• 0 0 1 * 1 — fires on the 1st of every month, AND every Monday, not just on Mondays that fall on the 1st.
• 0 0 1 * * — fires only on the 1st (DOW is wildcard, AND with everything).
• 0 0 * * 1 — fires only on Mondays (DOM is wildcard).

If you want "first Monday of every month" you cannot express it in standard cron — you need Quartz's 2#1 syntax, or you have to add a wrapper script that exits unless date +%d is between 1 and 7. AWS EventBridge punts on the issue entirely by requiring ? in one of the two day fields. The parser above implements POSIX semantics correctly.

Timezones — the source of every cron incident

Cron's biggest operational footgun is timezone handling. The rules vary by system:

• Linux crontab: uses the system timezone. Daylight-saving transitions can skip jobs (the 2:30 AM run on the spring-forward day never happens) or fire them twice (in the fall).
• Kubernetes CronJob: defaults to UTC. Set spec.timeZone: "America/New_York" to use a named TZ (Kubernetes 1.27+).
• GitHub Actions: always UTC, no override. If you want 9am Eastern, you have to convert: 9am EST = 14:00 UTC, 9am EDT = 13:00 UTC. Most teams just accept that the job drifts an hour at DST boundaries.
• AWS EventBridge: always UTC.
• Quartz: per-trigger TZ via scheduler.scheduleJob(jobDetail, trigger.withTimeZone(...)).

The defensive habit: always think about your cron in UTC unless your platform explicitly supports another zone, and document the intended local time in a comment next to the expression.

Cron in 8 platforms — real-world syntax

Here is the same intent — "every weekday at 9 AM" — expressed across the platforms you are most likely to ship to:

0 9 * * 1-5  /usr/local/bin/morning-job.sh

apiVersion: batch/v1
kind: CronJob
metadata:
  name: morning-job
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "America/New_York"   # k8s 1.27+
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: job
            image: ghcr.io/acme/morning:latest
          restartPolicy: OnFailure

on:
  schedule:
    - cron: "0 14 * * 1-5"   # 14:00 UTC = 9 AM EST (10 AM EDT)

cron(0 13 ? * MON-FRI *)

const cron = require('node-cron');
cron.schedule('0 9 * * 1-5', () => runMorningJob(), {
  timezone: 'America/New_York'
});

from apscheduler.schedulers.blocking import BlockingScheduler
from apscheduler.triggers.cron import CronTrigger
sched = BlockingScheduler(timezone='America/New_York')
sched.add_job(morning_job, CronTrigger.from_crontab('0 9 * * 1-5'))
sched.start()

@Scheduled(cron = "0 0 9 ? * MON-FRI", zone = "America/New_York")
public void morningJob() { /* ... */ }

c := cron.New(cron.WithLocation(time.FixedZone("EST", -5*3600)))
c.AddFunc("0 9 * * 1-5", morningJob)
c.Start()

Common cron mistakes to avoid

• Confusing */0 or */1 with "every minute". */0 is invalid; */1 equals *. Use plain * when you mean every value.
• Writing 0-59/5 when you meant */5. They are equivalent in the minute field, but the step form is shorter and clearer.
• Setting hour to 9 in UTC when you wanted 9am local. Always verify the platform's TZ before deploying.
• Forgetting that DOM + DOW are OR'd in POSIX. If you want "1st of the month, but only if it's a weekday," cron alone cannot do it.
• Running long jobs at * * * * * without overlap protection. If a job takes 90 seconds and runs every minute, you get overlapping instances. Use flock or a job queue to serialize.
• Treating cron triggers as exactly-once delivery. Most cloud cron systems are at-least-once. Make jobs idempotent.
• Scheduling everything for 0 0 * * *. If 200 jobs all run at midnight UTC, your worker pool spikes. Stagger across the hour.
• Not setting up alerts for missed runs. Use Healthchecks.io, Cronitor, or your platform's built-in failure notifications. Silent failure is the default.

Best practices for production cron

1. Make every job idempotent. Re-running it twice produces the same result.
2. Add overlap protection. Use distributed locks (Redis SETNX, etcd, ZooKeeper) or a job queue with single-runner semantics.
3. Set a job-level timeout. Cron has none. Wrap with timeout 5m or your platform's equivalent.
4. Use a dead-man's switch. Cronitor or Healthchecks.io tells you when a job did not run, which is the failure mode cron itself cannot detect.
5. Pin the timezone explicitly. Even if it matches the default, a comment makes future-you grateful.
6. Use named months and days for readability. 0 9 * JAN-MAR MON-FRI reads better than 0 9 * 1-3 1-5.
7. Stagger non-critical jobs. 17 * * * * instead of 0 * * * * spreads load.

Cron expression evaluator, validator, tester — what each query actually wants

Search variants for the same intent show up as: "cron expression evaluator", "cron expression validator", "cron tester", "cron evaluator", "cron formatter", "crontab online", "cron online", "cron syntax generator", "cron converter". They all ask the same three questions about a cron string: (1) is it syntactically valid? (2) what does it mean in plain English? (3) when does it next fire? The tool above answers all three on every keystroke.

Cron expression validator — how to tell a valid expression from a typo

A cron string passes validation when each of the five fields contains values inside its allowed range: 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 (both 0 and 7 mean Sunday on most cron implementations). The most-common typos: writing */5 in the day-of-month field (legal syntactically but semantically wrong — it means "every 5 days starting day 1"); using ? in standard cron (only valid in Quartz/AWS); and writing 0 0 31 2 * (Feb 31 — never fires). The validator above flags all three with explicit error text instead of silently accepting unreachable schedules.

Cron tester / cron evaluator — see the next 10 fire times before deploying

Validating syntax is half the work. The other half is confirming the expression actually fires when you expect. Paste any expression above and the next 10 fire timestamps render below in your local timezone — useful for catching bugs like "0 9 * * 1" (Mondays 9 AM) when you meant "0 9 * * 1-5" (weekdays). For schedule expressions targeting servers in a different timezone, set the timezone selector before reading the next-run list. The evaluator runs cron-parser semantics matching Vixie cron and most standard implementations.

Cron converter — translating between Vixie cron, Quartz, and AWS EventBridge

"Cron converter" usually means one of three translations: Vixie cron → Quartz (Quartz adds a seconds field at the start: 0 0 9 * * ? instead of 0 9 * * *); Quartz → AWS EventBridge (EventBridge uses 6 fields with a year, plus uses ? instead of * in either day-of-month or day-of-week); Vixie → Kubernetes CronJob (identical syntax, but with a 1-minute resolution and timezone via the timeZone field as of Kubernetes 1.27+). The parser above accepts all three formats with auto-detection — paste a 6-field Quartz expression and it adapts; paste a standard 5-field expression and it stays in Vixie mode.

Crontab online — running cron locally vs in the cloud

The traditional crontab -e CLI edits /var/spool/cron/<user> on Unix systems and the cron daemon picks it up on save. The expression above runs the same parsing logic that cron, vixie-cron, cronie, and modern systemd timers use, so anything that validates here works on a Linux server. For cloud schedulers — AWS EventBridge, Google Cloud Scheduler, Azure Functions Timer Trigger — note their year and seconds field extensions; the differences page in the FAQ below covers each provider's exact format.

C# cron expression parser, Quartz cron, NCrontab — language-specific notes

For C# / .NET the standard library is NCrontab (5-field Vixie semantics) or Quartz.NET (6-field with seconds). For Node.js: cron-parser (the same parser this page uses), node-cron, or node-schedule. For Python: croniter (next-fire calculation), APScheduler (full scheduler). For Go: github.com/robfig/cron/v3. For Java: Quartz Scheduler. The expression above mirrors NCrontab/croniter/cron-parser semantics — patterns valid here behave identically in all three.

Cron syntax generator — building expressions from natural language

Going the other direction — describing a schedule in English and getting cron back — is what most "cron syntax generator" searches actually want. Common conversions: "every weekday at 9 AM" → 0 9 * * 1-5; "every 15 minutes during business hours" → */15 9-17 * * 1-5; "first day of every month at midnight" → 0 0 1 * *; "every Monday and Wednesday at 8:30 PM" → 30 20 * * 1,3; "every 6 hours" → 0 */6 * * *. Keep these as a starting point; tweak in the parser above and watch the next-run list update.