Cron Parser

What is this tool?

A free cron expression parser for the standard 5-field crontab format — the one used by Linux cron, Kubernetes CronJobs, GitHub Actions schedules, and most CI and cloud schedulers. Paste an expression and it is decoded instantly: a plain-English sentence saying when it fires, a field-by-field breakdown, and the next 10 concrete run times, shown in your own timezone or in UTC. No more counting on your fingers whether 0 */6 * * 1 means what you hoped.

Everything you paste stays in the browser. The parser is deterministic code running on your device — no uploads, no sign-up, and the page keeps working offline once loaded. The only thing stored is your last expression, in your own browser's local storage. The one optional exception is the AI builder —off by default — which is this tool's twist:

The AI twist

Writing cron backwards — from "I know when I want it to run" to five cryptic fields — is the part everyone googles. Flip theAI build switch and describe the schedule in plain English: "every weekday at 9:30", "midnight on the first of every month", "every 15 minutes during office hours". A small language model writes the expression — and here's the part that makes it trustworthy: the answer drops straight into the parser above, so you immediately see it decoded back into English and expanded into real run times. If the model misunderstood you, the run times betray it instantly; if it got it right, you can see that too, before anything lands in a crontab.

The model is not a cloud API: it's a compact open-weights model running on this website's own server — the same machine that writes patterns for the regex checkerand plays TrickGuard. Your description is the only thing sent, nothing about you is stored with it, and identical descriptions are answered from a cache. Because the hardware is a modest CPU, an answer takes a few seconds. Want a different take? Just ask again.

How to use it

• Paste or type a cron expression — five fields separated by spaces: minute, hour, day of month, month, day of week.
• Read the English description and scan the field table to confirm each part means what you intended.
• Check the next 10 run times — switch between your local timezone and UTC (most servers and CI schedulers run cron in UTC).
• Macros work too: try @daily, @hourly or @weekly.
• Going the other way? Flip on AI build, describe the schedule in words, and verify the result against the run times.

Cron format quick reference

A crontab expression is five fields, left to right:

Special characters

Common expressions

Macros

The day-of-month vs day-of-week gotcha

The most misread rule in cron: when both the day-of-month and day-of-week fields are restricted, standard cron runs wheneither one matches — not both. So0 0 13 * 5 does not mean "Friday the 13th"; it fires on every 13th and on everyFriday. This tool warns you when an expression triggers the rule, and the run-time preview makes the actual behaviour obvious. (Quartz-style schedulers use ? to sidestep this — if you paste one, the ? is accepted and treated as*.)

Timezones & daylight saving

• A cron expression has no timezone of its own — it fires by the wall clock of whatever runs it. On a server that's the system timezone (check with timedatectl); GitHub Actions, Kubernetes CronJobs (by default) and most cloud schedulers use UTC. That's why this tool shows both: preview in your local time for your own machine, switch to UTC for CI and servers.
• Daylight saving is cron's classic footgun: a job at30 2 * * * simply doesn't happen on the night the clock jumps from 02:00 to 03:00, and may run twice when clocks fall back (implementations vary — vixie cron tries to compensate, many others don't). The local preview here skips wall-clock times that don't exist. Rule of thumb: schedule nightly jobs outside 01:00–03:00, or use UTC.

What this tool doesn't parse

The nonstandard extensions some schedulers bolt on: Quartz's 6/7-field seconds-and-years format (paste one and you get a pointer instead of a wrong answer), and the Quartz/AWS tokensL (last day), W (nearest weekday) and# (nth weekday of the month). If your scheduler speaks those, its own docs are the source of truth — for everything crontab-standard, this page has you covered.

FAQ

Is it free? Yes — free, no sign-up, no limits.

Is my expression uploaded anywhere? No. Parsing, describing and computing run times all happen in your browser — the parsing side of the page works the same if you go offline after loading it. The optional AI builder — only if you've switched it on — sends exactly one thing, the description you typed, to this site's own server, where a local model answers it. No third-party AI service ever sees it.

Can AI really write my cron expression? For the schedules people actually use — dailies, weekdays, every-N-minutes, monthly jobs — yes, reliably. And unlike a chatbot answer, the result is verified in front of you: decoded back to English and expanded into the next 10 run times. If the expression is wrong, you'll see it in the dates before it ever reaches a server.

Why does my job fire way more often than I meant?Two usual suspects: a * left in the minute field (* 9 * * * runs 60 times between 9:00 and 9:59 — you probably meant 0 9 * * *), or the day-of-month/day-of-week OR rule explained above. Both are visible at a glance in this tool's run-time preview.

What timezone does my real cron job use? The system timezone of the machine (or scheduler) that runs it — not yours. GitHub Actions and most managed schedulers use UTC. Preview in UTC here, then convert.

Does this cover GitHub Actions / Kubernetes CronJob syntax? Yes — both use the standard 5-field POSIX format this tool parses (Kubernetes also honours the @macros).