How this converter works
A standard cron expression is five fields: minute, hour, day of month, month and day of week. Each accepts a number, a range (1-5), a list (1,3,5), a step (*/15) or *. Quartz and Spring add a seconds field in front, Quartz and AWS add a year at the end, and those three also understand L (last), W (nearest weekday) and # (nth weekday). Auto-detect picks the dialect from the number of fields, the position of ?, and the cron(...) wrapper; pick one explicitly to override it.
Each field is expanded to the exact values it matches, then the parser walks the calendar forward (and back, for previous runs), skipping whole years, months, days and hours that can't match, so even schedules that fire once a decade are found instantly. Runs are computed on the wall clock of the chosen time zone and converted to real instants with the browser's time-zone data: a run inside a spring-forward gap is reported as skipped, and fall-back hours follow Vixie cron's rule — fixed-time jobs fire once, jobs with * in the time fields fire in both passes.
The day fields are the classic trap. In standard cron, Kubernetes and GitHub Actions, when both day-of-month and day-of-week are restricted the job fires when either matches, so 0 0 1 * 1 runs on the 1st and on every Monday. Spring and node-cron require both; Quartz and AWS forbid setting both and need ? in one. The warnings panel calls out this and other common mistakes: * in the minute field, days that don't exist in some months, steps that don't divide evenly, 1-based weekdays in Quartz, and GitHub's five-minute minimum.
Paste a whole crontab (comments, MAILTO= and CRON_TZ= lines included) to get a table of every job with its meaning and next run. Switch to English → cron to type a schedule such as "every 15 minutes between 9am and 5pm on weekdays" and get the expression in the dialect you choose — or paste an expression there to convert it between dialects.
Frequently asked
What does */6 mean in the hour field?
Every sixth value starting at zero: hours 0, 6, 12 and 18 — the same as 0,6,12,18. A step restarts at each boundary, so */7 in the minute field runs at :49 and :56 and then :00, a 4-minute gap; the tool warns about steps like that.
Why does my cron run on the wrong day?
In standard cron, day-of-month and day-of-week combine with OR when both are restricted, so either match triggers the job. Use * in one of them when you want a single condition. Spring and node-cron use AND instead, and Quartz and AWS require ? in one of the two fields.
Does this support seconds, Quartz and AWS syntax?
Yes. Six fields with seconds (Spring @Scheduled, node-cron), Quartz's six or seven fields with ?, L, W, LW, L-n and #, and AWS EventBridge cron(...) with a year field and rate(...) are all supported. Auto-detect usually picks the right one; choose a dialect to be explicit.
Which time zone is used?
Your browser's zone by default, or any IANA zone you pick (choose Other to type one) — GitHub Actions is always UTC, and AWS and Kubernetes default to UTC. A CRON_TZ=Europe/Berlin line or prefix in the input also sets it. Daylight-saving changes are applied: the warnings say when a run falls in a skipped or repeated hour in the next year.
Why does * 9 * * * run 60 times?
Because * in the minute field means every minute, so it fires at 09:00, 09:01 … 09:59. For once at 9am write 0 9 * * *.
How do I run something on the last day of the month or the first Monday?
Quartz, Spring and AWS have L (last day) and 2#1 / MON#1 (first Monday). Standard cron can't express either directly — 1-7 with a weekday would be an OR, not an AND — so the usual trick is to schedule 28-31 or 1-7 and test the date in the command. English → cron produces the Quartz form automatically.
Can I convert a cron expression between dialects?
Yes. Paste it into English → cron and pick the target dialect: 0 9 * * 1-5 becomes 0 0 9 ? * MON-FRI for Quartz or cron(0 9 ? * MON-FRI *) for AWS. If the target can't express the schedule (seconds, L or an OR of both day fields), it says why.