Cron Expression Parser

Parse, explain, and generate cron expressions. Understand cron schedules with human-readable descriptions and next run times.

A cron parser reads the five fields of a cron expression - minute, hour, day of month, month and day of week - and tells you in words when the job runs, plus the next times it will fire. Type into Cron expression and the page reparses on every keystroke; the default */5 * * * * is described as Every 5 minutes and the next five run times are listed underneath.

Minute
0-59
Hour
0-23
Day
1-31
Month
1-12
Weekday
0-6

🕐 Next Runs

Examples

Embed this tool on your website

× px

                        

💡 Integration Tip

Copy the embed code and paste it into your website HTML. The responsive version adapts to all screen sizes automatically.

0 ratings

About Cron Expression Parser

The page splits your expression on whitespace and insists on exactly five fields; anything else shows the invalid-expression message and clears the results. The five parts are then shown in labelled boxes - Minute, Hour, Day, Month, Weekday - so you can see which value landed where, which is where most cron mistakes actually are.

Two outputs follow. The description turns each field into a phrase: a star becomes every minute or is left out, */n becomes every n minutes or hours, a comma list becomes at minutes 0,30, a range becomes minutes 10-20, and a weekday number becomes a day name from your locale. The next-runs list is computed by brute force: the page starts at the current minute and steps forward a minute at a time, up to a year ahead, collecting the first five moments that match. An expression with no match inside a year - 30 February, for example - therefore produces an empty list rather than an error.

Those next times are computed in your browser's own time zone, using the local Date methods, and formatted with your locale. A real cron daemon uses the time zone of the machine it runs on, so a schedule that reads correctly here can fire at a different clock time on the server. Check the server's zone before trusting the list for a deployment.

Two behaviours differ from a Unix crontab and are worth knowing. When both the day-of-month and the day-of-week fields are restricted, crontab(5) says the command runs when either field matches; this page requires both to match, so it will show fewer runs than the server would. And it accepts only numbers with the *, comma, hyphen and slash operators: the nicknames @daily, @hourly and @reboot, and the three-letter month and day names, are not recognised.

Use Cases

A developer reviewing a colleague's deploy script pastes the expression from the crontab and reads the plain sentence, which is faster and safer than counting the star positions by eye.
Someone setting up a nightly backup uses the 0 0 * * * example, sees Every day at midnight, and checks that the first listed run really is tonight rather than tomorrow.
An on-call engineer working out why a job fired at an unexpected hour pastes the expression and compares the next-run list with the log timestamps to see whether the schedule or the server clock is at fault.
A student learning cron clicks through the ten examples, from * * * * * to 0 0 * * 0, and watches which of the five boxes changes for each one.
Someone tightening a schedule that runs too often changes */5 to */30 in the field and watches the next-run list spread out before committing the change.

How to use

1

Type or paste your expression into the Cron expression field; it is parsed on every keystroke, with */5 * * * * there to start.

2

Read the plain-language description under the field to check the schedule says what you meant.

3

Look at the Minute, Hour, Day, Month and Weekday boxes to confirm each value landed in the field you intended.

4

Read the next run times listed below, remembering they are in your own time zone rather than the server's.

5

Click one of the ten examples, from every minute to first day of the month, to load a known-good expression and adapt it.

6

Press the copy button beside the field to put the finished expression on the clipboard.

Pro Tips

  • Read the five boxes under the field before the description. Minute, Hour, Day, Month, Weekday in that order is where a schedule that is one field out shows itself immediately.
  • Treat the next-run list as your clock, not the server's. It is built with your browser's local time, so compare it against the server's time zone before you commit a crontab line.
  • Write @daily and friends out in full. The parser wants five numeric fields, so use 0 0 * * * for @daily, 0 * * * * for @hourly and 0 0 1 * * for @monthly; there is no equivalent for @reboot.
  • Avoid combining a day of the month with a weekday. A Unix crontab runs the job when either matches, this page requires both, and the two readings differ by a lot; put the second rule in its own crontab line instead.
  • Click an example first, then edit one field. The ten presets cover every common shape, and changing a single value in a known-good expression is far less error-prone than typing five fields from scratch.

Troubleshooting

Problem:

The page says the expression is invalid.

Solution:

It requires exactly five whitespace-separated fields. Six fields, which some schedulers use for seconds, a nickname such as @daily, or a stray space inside a comma list will all fail this check. Count the fields, and write nicknames out in numeric form.

Problem:

No next run times are listed even though the expression looks fine.

Solution:

The search only looks one year ahead, minute by minute, so a combination that never occurs - the thirtieth of February, for example - or one that falls outside the window returns nothing. Loosen a field and watch the list reappear to find which one is impossible.

Problem:

The listed times do not match when the job actually ran on the server.

Solution:

The list is built in your browser's time zone and the daemon uses the server's. A machine on UTC and a laptop on CEST will disagree by an hour or two. Check the server's zone, and remember that a daylight-saving change shifts the local list but not a UTC crontab.

Problem:

A range with a step, such as 10-20/2, matches values above the range.

Solution:

The step check on this page takes the start of the range and then accepts every nth value from it, without enforcing the upper bound, so 10-20/2 also matches 22 and 24. Write out the values you want as a comma list - 10,12,14,16,18,20 - to get exactly the range you intend.

Frequently Asked Questions

A scheduler on Unix-like systems that runs commands at fixed times. Each line of a crontab file holds five time fields followed by the command; the daemon wakes every minute and runs whatever matches. The five fields are minute, hour, day of month, month and day of week, in that order, which is what this page parses.

Every minute of every hour of every day. A star means no restriction on that field, so with all five unrestricted the expression matches every minute the daemon checks. It is the most frequent schedule cron can express; anything more often needs a different tool, because cron's resolution is one minute.

Use 0 0 * * *: minute 0, hour 0, any day of month, any month, any day of week. The page shows it as Every day at midnight and lists tonight as the next run. For a weekly midnight job add a weekday in the fifth field, so 0 0 * * 0 is midnight on Sunday.

Minute 0-59, hour 0-23, day of month 1-31, month 1-12, and day of week 0-6 with 0 as Sunday. The boxes below the input repeat that order with the value you typed in each, which is the quickest way to spot a schedule that has slipped one field to the left or right.

5 means at minute five of every hour, once an hour. */5 means every fifth minute - 0, 5, 10 and so on - twelve times an hour. Mixing them up is the classic cron mistake, and the description line here says Every 5 minutes for one and At minute 5 for the other, which makes it obvious.

Yours. The page steps forward using your browser's local clock and formats the results in your locale. A cron daemon uses the time zone of the machine it runs on, so if your laptop and the server disagree, so will the times. Confirm the server's zone before relying on the list.

No. The parser requires exactly five whitespace-separated fields of digits and the *, comma, hyphen and slash operators. Nicknames such as @daily, @hourly and @reboot, and the three-letter forms JAN and MON that many crons accept, are not recognised here; write the numeric equivalent instead - @daily is 0 0 * * *.

Because this page requires both fields to match, while a Unix crontab does not. The crontab(5) manual states that if both fields are restricted, the command runs when either field matches. So 0 0 13 * 5 runs on every 13th and every Friday on a real server, but this page lists only Friday the 13th.

Because nothing matched within a year of searching. The page steps forward minute by minute for up to 525,600 minutes, so an impossible combination such as 0 0 30 2 * - the thirtieth of February - simply finds nothing. A rare but valid schedule, such as 29 February, may also fall outside the window.

That is what it is for, with two cautions. Read the next-run times as your local clock rather than the server's, and remember the day-of-month and day-of-week difference above. Within those limits, seeing the first five firing times is the fastest way to catch a schedule that is an hour or a field out.

Popular Tools

No more tools to show
Explore All Tools
FreeWebTools AI
Powered by free AI models · Full chat →