Cron Decoder - decode any cron expression online

• Labelled fields. Each token sits in its own editable field (minute, hour, day of month, month, day of week) with a help popover that gives the range and syntax.
• One English sentence for the whole expression, written by cronstrue in English with a 24-hour clock.
• Next runs: the next five timestamps from now, in the IANA timezone you pick.
• A month calendar with Prev, Today and Next. On mobile it becomes an agenda of up to 30 runs from the visible month.
• Validation. An invalid field is highlighted with a readable parser error, and a fixed day and month that can't exist, like 0 0 30 2 *, is reported as never firing.
• Copy actions: Copy, Copy English, Copy link, Run in Crontap, and Copy as, which rewrites the schedule as a crontab line, vercel.json, GitHub Actions, Kubernetes CronJob, AWS EventBridge or Quartz, or exports the next runs as Markdown.

Standard mode reads five fields. Extended mode adds a leading seconds field and a trailing year; if you paste six fields while in Standard mode, CronTool asks before switching. There's no dialect selector, so the decoder tells you what the fields say, not whether your target scheduler accepts them.

Paste only the schedule, not a whole crontab line: the decoder doesn't parse the command after the five fields. To read a full crontab, save crontab -l to a file and upload it to the multi-cron visualizer, which takes the first five fields of each line and skips comments, variables and @daily-style lines.

Read the five fields from left to right: minute, hour, day of month, month and day of week. A run happens in every minute where all five match. Here is the editor's default, */15 9-17 * * 1-5, taken apart:

• */15 in the minute field steps through the hour in 15s, so minutes 0, 15, 30 and 45.
• 9-17 in the hour field is every hour from 09 to 17 inclusive. The last run is 17:45, which is why the sentence says “between 09:00 and 17:59” rather than “until 17:00”.
• * and * leave day of month and month open, so any date qualifies.
• 1-5 in the day of week field is Monday (1) through Friday (5).

Put together, that's four runs an hour for nine hours, or 36 runs on each weekday and none at the weekend, which is exactly what the calendar shows. When a sentence surprises you, this is the check to do: read each field on its own, then see which minutes survive all five.

These are CronTool's exact sentences in Standard mode:

• * * * * * → Every minute
• */5 * * * * → Every 5 minutes
• 0 * * * * → Every hour
• 0 0 * * * → At 00:00
• 0 9 * * 1-5 → At 09:00, Monday through Friday
• 30 8,17 * * * → At 08:30 and 17:30
• 0 0 1 * * → At 00:00, on day 1 of the month
• 0 0 1,15 * * → At 00:00, on day 1 and 15 of the month
• 0 0 L * * → At 00:00, on the last day of the month (L is an extension, not classic Unix cron)

Quartz expressions need Extended mode, because Quartz puts seconds first and allows an optional year at the end:

• 0 0 0 ? * MON-FRI → At 00:00, Monday through Friday
• 0 0 0 LW * ? → At 00:00, on the last weekday of the month
• 0 0 9 ? * MON#2 → At 09:00, on the second Monday of the month

AWS EventBridge also uses six fields, but minutes first with a required year, and one day field must be ?: weekdays at midnight is cron(0 0 ? * MON-FRI *). CronTool has no AWS mode and favours the seconds-first reading for six fields, so don't paste the AWS form. Decode the schedule here, then use Copy as → AWS EventBridge, which adds the ? and the year for you.

These four aren't part of classic Unix cron. Quartz and AWS document them, robfig/cron accepts only ?, and other libraries vary, so the sentence tells you what the field means, not that your scheduler accepts it.

• ? means “no specific value”. Quartz and AWS require it in one of the two day fields, which is why 0 0 0 ? * MON-FRI leaves day of month open and lets day of week decide.
• L means last. In day of month, 0 0 L * * is the last day of every month; the last-day-of-month guide covers each dialect's version.
• W picks the weekday nearest a date, so 15W is the Monday to Friday closest to the 15th, and LW is the last weekday of the month.
• # picks the nth weekday of the month: MON#2 is the second Monday.

A scheduler checks each minute against every field and fires when they all match. The sentence summarises those rules well, but a few cases only show up once you look at real dates.

• When both day fields are set, either one triggers a run. 0 9 1 * 1 decodes to “At 09:00, on day 1 of the month, and on Monday”, and Unix cron runs it on the 1st and on every Monday, not only on Mondays that fall on the 1st. Quartz and AWS avoid this by requiring ? in one day field.
• Steps restart at the field boundary. 0 0 */7 * * reads as “At 00:00, every 7 days”, but it fires on the 1st, 8th, 15th, 22nd and 29th, then starts over on the 1st. Ranges don't wrap either: 50-10/20 isn't minutes 50, 10 and 30. CronTool still writes a sentence for it, so write the list out instead: 10,30,50.
• Weekday numbers differ by dialect. Unix cron accepts 0 or 7 for Sunday, while Quartz and AWS count 1 to 7 with Sunday as 1. CronTool's sentence uses Unix numbering, so a numeric Quartz weekday reads one day off. Names like MON mean the same thing everywhere.
• Some dates never come. 0 0 30 2 * decodes to “At 00:00, on day 30 of the month, only in February”, which sounds fine and never fires; so does 0 0 31 2 *. 0 0 29 2 * runs only in leap years, and 0 0 31 * * skips February, April, June, September and November.
• Daylight saving bends local times. A job at 02:30 local time has no 02:30 on the spring-forward night and two of them in autumn. Schedulers handle that differently, so check yours, or keep jobs out of the 01:00 to 03:00 window or in UTC.

That's why CronTool leads with a calendar rather than a long list of timestamps. A list is fine for something that fires every few minutes, but it hides the shape of slower schedules: on the calendar you see the extra Mondays next to the 1st, the missing 31sts, or a weekend run you didn't mean. Step through a few months with Prev and Next before you trust a monthly job. With several jobs, the multi-cron visualizer puts them on one calendar and lists up to five pairs that fire in the same minute.

The decoder answers “what does this cron mean, and when does it run?”. A few neighbouring questions have their own pages:

• Cron tester: is the syntax valid before you ship it?
• Cron debugger: the schedule looks right, so why isn't the job running?
• Cron analyzer: how do several crons overlap and bunch up?
• Cron parser: which library parses cron in your language, for decoding in code?
• Cron builder: you know the schedule and need the expression.
• Cron cheatsheet: field ranges, operators and dialect differences on one page.