Cron Expression Parser

Paste a cron line and this parser reads it back in plain English, then lists the next five times it actually fires as real dates. Free, no sign-up, and the whole thing runs in your browser so nothing gets uploaded. Type 0 9 * * 1 and you get back "At 09:00, on Monday" plus the next five Mondays it'll trigger.

That next-run list is the point, more than the translation. Most of us can half-read a cron line and feel sure we've got it, and cron has one rule that runs backwards from how everyone reads it. So the real test is the next five dates. If they match what you pictured the line is right, and if they don't you just caught a bug before it shipped instead of at 3 AM when the backup ran twelve hours off.

Take 0 0 13 * 5. Read it out loud and most people land on "midnight on Friday the 13th," which is not what it does. Neither day field starts with a *, and in that case cron fires whenever either one matches. So that line runs at midnight on every 13th of the month and again every Friday, which can be five or six nights instead of the single one you pictured. This parser is built around catching exactly that: it writes OR into the description on purpose, the panel says why, and the next-run list computes the real OR schedule, so the dates on screen are the dates your scheduler will actually pick.

1. Paste your expression into the box. Standard five fields, space-separated: minute, hour, day-of-month, month, day-of-week. Something like 30 8 * * 1-5.
2. Read the plain-English line. It comes back as a sentence, "At 08:30, Monday through Friday," so you can sanity-check the meaning in a second.
3. Scan the next five run times. Real dates, computed from right now. This is where a misread shows itself, if the dates look wrong the expression is wrong.
4. Flip the time zone. Toggle between your local zone and UTC (more on why that matters below).
5. If a field is out of range or malformed you get a specific message naming the field and the problem, not a stack trace.

This is the most misread rule in cron, and it's worth slowing down on because your eyes will lie to you here.

Normal intuition says a schedule with a day-of-month AND a day-of-week both filled in should mean "only when both line up", and cron often reads it the other way entirely. crontab(5) puts it like this: "If both fields are restricted (i.e., aren't *), the command will be run when either field matches the current time."

The code is narrower than that sentence, and this is where even careful readers get caught. Vixie cron decides the operator from the FIRST CHARACTER of each day field, before it parses the field at all. If either field begins with a * it uses AND, and only if neither does will it use OR. That splits two cases the man page's wording puts on the same side:

• 0 0 */2 * 5 looks restricted in both day fields, so the sentence predicts OR. But */2 begins with a star, so cron ANDs: odd-numbered days that are also Fridays, roughly 26 nights a year rather than the 212 an OR would give.
• 0 0 1-31 * 5 also looks restricted in both, and here cron really does OR. 1-31 covers every day there is, so the union is every day, and the job runs nightly rather than on Fridays.

This parser reads the raw tokens the same way cron does, so the word in the description and the dates in the list both follow the implementation rather than the paraphrase.

The practical upshot: leave one of the two day fields as a plain * and you're safe, because an AND against "every day" is just the other field deciding, exactly as you'd expect. Restrict both with fixed values only when you actually want the union. And if what you really need is "Friday the 13th, and only then," plain cron can't say it in a single line. You schedule the looser trigger, 0 0 13 * * for every 13th, and add an "is it Friday?" check at the top of the script.

The reason this tool exists is to make that invisible rule visible. It names the operator in words, says which character decided it, and proves it in dates, so a schedule that would have quietly fired five extra times a month gets caught while you're still looking at it.

Your line says 0 9 * * * and you're picturing 9 in the morning. The question the machine cares about is 9 AM on whose clock. Cron fires against the clock of the box that runs it, and that box is very often not set to your zone. GitHub Actions cron runs in UTC, no exceptions. AWS EventBridge scheduled rules default to UTC. Piles of cloud servers ship set to UTC by convention. So 0 9 * * * on GitHub Actions goes off at 9 AM UTC, which could be 4 AM or 1 AM where you sit.

That's the reason for the UTC toggle. By default the run list is in your browser's local zone, which answers "when does this hit me." Switch it to UTC to see what a UTC-based scheduler does with the same string. When those two disagree with your intention, you've found a time-zone bug before it fired at the wrong hour, and setting the right hour is just arithmetic from there (0 14 * * * for a 9 AM run at UTC minus 5).

One more reading mistake worth knowing, because it looks fine until you check the dates. A step like */15 in the minute field means every 15 minutes, and it lands clean at :00, :15, :30, :45. But steps count from the field's minimum and reset at the wrap, they don't space themselves evenly around the clock. So */40 fires at :00 and :40, then the hour rolls over and it starts again at :00. The real gap between :40 and the next run is 20 minutes, not 40. You'd never guess that from the string, and it's the kind of thing the next-run list surfaces on sight because the timestamps come out uneven.