WMCoder

Cron Expression Parser — Human-Readable Schedules

Turn cron expressions into clear language, field meanings, and upcoming run times—right in the browser, without sending schedules to a server.

How cron expressions map to real clocks

Cron packs a repeating schedule into a compact line: which minutes, hours, days, and weekdays qualify for a run. The same string can mean different things on different systems—especially around daylight saving, timezone defaults, and nonstandard characters—so treat this parser as a fast sanity check, then confirm in your actual job runner. When you need to reason about instants and offsets across zones, pair schedules with Timestamp Formatter for concrete wall-clock examples.

Five vs six fields and common gotchas

Most Linux crontab entries use five fields. Orchestrators and some libraries add seconds first for finer control. Mixing formats between tools produces silent “wrong schedule” bugs: always match the field count your engine documents. Ranges like 1-5 on day-of-week typically mean Monday–Friday in 0–7 schemes, but verify your platform’s Sunday value (0 vs 7). Steps like */15 in the minute field mean “every 15 minutes from minute 0,” not “from now.” For pattern-heavy strings you assemble programmatically, Regex Tester can help validate the generator output before it hits production config.

Operational habits that keep schedules predictable

Store cron source in version control with a short comment describing intent and timezone assumptions. After changes, compare “next run” output here or in your scheduler against on-call expectations—especially around month-end and leap years. When configs are embedded in JSON or YAML, keep quoting and escaping consistent; JSON Formatter is useful when a deployment manifest is hard to read. For security-sensitive jobs, avoid pasting credentials into any tool; cron lines should reference secret stores, not literal passwords.

Frequently Asked Questions

What is the field order for a standard 5-field cron expression?
From left to right: minute (0–59), hour (0–23), day of month (1–31), month (1–12 or names), day of week (0–7, where 0 and 7 often mean Sunday). Spaces separate fields; some engines allow multiple spaces, which this tool normalizes.
When should I use 6 fields instead of 5?
Six-field expressions add a leading seconds field (0–59). Use them when your scheduler or library expects Quartz-style or second-level precision. Classic Unix crontab and many platforms use five fields only—check your runtime before adding seconds.
Why might human-readable text differ slightly from my server’s behavior?
Cron has dialects: Sunday numbering, DST handling, and support for `?`, `L`, `W`, or `#` vary by implementation. This tool uses common parsing libraries in the browser; always validate critical jobs in the same environment that will execute them (e.g. your orchestrator or OS cron).
How do I debug a schedule that never seems to run?
Confirm field count, ranges, and step values (`*/n`). Check that day-of-month and day-of-week are not unintentionally exclusive on your platform. Compare the next run list here with a log or dry-run in your scheduler; for time zones, align server TZ with what you expect.
Is my cron expression sent to a server?
No. Parsing runs entirely in your browser. Expressions are not uploaded for this tool; use the same caution as any local page when pasting secrets into unrelated fields elsewhere.