Cron Expression Parser & Next Run Calculator

Parse a cron expression (minute hour day month weekday) and see a plain-English description of its schedule. Supports steps, ranges and lists, and calculates the next 5 run times. Handy for reading crontab entries or a GitHub Actions schedule.

Last updated: 2026-09-06

Cron expression syntax (5 fields)

A cron expression has 5 space-separated fields, from left to right: minute, hour, day of month, month, and day of week. Each field accepts the special characters below.

Position	Field	Allowed values
1	Minute	0-59
2	Hour	0-23
3	Day of month	1-31
4	Month	1-12
5	Day of week	0-7

Day of week is normally 0 = Sunday through 6 = Saturday, but this tool also accepts 7 as an alias for Sunday, as used by some cron implementations (it is treated the same as 0).

Each field can use "*" (any value), comma-separated lists (1,15,30), hyphen ranges (1-5), and slash steps (*/15, 1-30/5) — and these can be freely combined.

Common cron patterns

Cron expression	Meaning
* * * * *	Runs every minute.
/5 * * *	Runs every 5 minutes.
0 * * * *	Runs once an hour, at minute 0.
0 0 * * *	Runs daily at midnight (00:00).
0 9 * * 1-5	Runs at 9:00 on weekdays (Monday through Friday).
0 0 1 * *	Runs at midnight on the 1st of every month.
0 0 1 1 *	Runs at midnight on January 1st every year.
/15 9-17 * 1-5	Runs every 15 minutes between 9:00 and 17:00 on weekdays.

What a cron expression is

A cron expression states, on a single line, when a repeating job should run. Five fields — minute, hour, day of month, month, day of week — are set out from the left, separated by spaces, and each may combine * for every value, a comma-separated list, a hyphenated range and a slashed step. */15 9-17 * * 1-5 therefore means “every fifteen minutes from nine to five, Monday to Friday”.

This tool parses what you enter and, **having stated the schedule in words, works out the next five times it will run** counting from now. The breakdown by field is set out alongside, so you can see which part is doing the work. Day of week runs from 0 for Sunday to 6 for Saturday as standard, but the 7-for-Sunday form used by some implementations is accepted too and treated internally as 0. The search for future runs reaches about four years ahead; if nothing matches within it, that is said plainly.

How to use the cron parser

Enter the expression Give the five fields — minute, hour, day, month, day of week — separated by spaces. A wrong number of fields, or a value out of range, raises an error.
Press parse The meaning of the schedule appears in words. Check here first that you have not misread your own expression.
Look over the field breakdown What each of minute, hour, day, month and day of week stands for is listed. It shows up any field carrying a value you did not intend.
Read the coming runs The next five moments are given as dates and times. A mismatch with your intention — specifying the 31st, say, in months that have no such day — appears as concrete dates.
Borrow from the common patterns A table collects the familiar ones: every minute, every five minutes, on the hour, nine o’clock on weekdays. Starting from the nearest and editing it is the quick way.

Tips for getting more out of it

Fields can freely combine comma lists, hyphen ranges, and slash steps, e.g. "*/15 9-17 * * 1-5".
Day of week is normally 0-6 (Sunday-Saturday), but this tool also accepts 7 as a common alias for Sunday used by some cron implementations.
If both the day-of-month and day-of-week fields are restricted (not "*"), standard cron treats them as an OR condition — the job runs when either one matches.
GitHub Actions' schedule trigger uses the same 5-field cron syntax as this tool, so you can use it to check exactly when a workflow will run.
The actual run time depends on the server's timezone setting, so after editing a crontab it is worth double-checking the server's current time as well.

Where the cron parser helps

Confirming the meaning before it goes into crontab

Parsing it before you register it on a server heads off the mishaps of a job running far more often than you meant, or never at all.

Checking a GitHub Actions schedule

The expression under a workflow’s schedule uses the same five-field notation. The list of coming runs shows whether the interval is what you intended.

Making sense of somebody else’s expression

When a configuration you have inherited carries something like 0 */6 * * *, putting it into words tells you at once what hours it fires at.

Investigating a run that went astray

When a job did not run at the hour it should have, the list of coming runs separates “the expression itself is the cause” from “something else is”.

When you want to count the days between runs

To count how long until the next run, use the countdown timer; to count in working days, the business-day calculator.

Terms used with cron

cron: The facility on Unix-like systems for running jobs repeatedly at set times. The table pairing each job with its schedule is called a crontab.
Field: Each element of a cron expression, separated by spaces. From the left they are minute (0–59), hour (0–23), day of month (1–31), month (1–12) and day of week (0–6).
Asterisk: Stands for every value the field can take. Placed in the minute field it means every minute; in the month field, every month.
Step: Written as */15 and the like to state an interval. It picks values across the range at a fixed stride — every fifteen minutes, for instance.
Range: Written as 1-5 to take a run of consecutive values together. In the day-of-week field that is Monday to Friday; in the hour field, one o’clock to five.
Day-of-week numbering: 0 is Sunday and 6 is Saturday. Some implementations also accept 7 for Sunday, and this tool treats 7 as the same as 0.
Time zone: cron is ordinarily read in the time of the environment it runs in. If a server’s clock setting differs from what you assumed, the same expression will fire at a different hour.

Frequently Asked Questions

Yes. The standard cron specification uses 0 for Sunday, but some implementations (such as Vixie cron) also accept 7 as an alternate notation for Sunday. This tool treats both as Sunday.

Neither takes priority — they're combined with an OR condition. When both the day-of-month and day-of-week fields are restricted (not "*"), the job runs on any day that matches either one. If only one field is restricted, only that field's condition applies.

The basic 5-field format (minute hour day month weekday) is the same. The key differences are that GitHub Actions schedules are always evaluated in UTC, and the actual run can be delayed by several minutes to tens of minutes, unlike a server's crontab.

Yes, step values (either a starting value with a slash, or */interval) can be used in any of the five fields. That said, fields with a small range, like month or day of week, have limited practical use for steps.

Side Note — Half a Century of Cron

The name "cron" is said to derive from Chronos, the Greek word for time, and it has been a staple job scheduler since the early days of UNIX in the 1970s. Its compact five-field syntax can express anything from "every minute" to "a specific date and time once a year", and it is still widely used nearly half a century later.

Today, this same 5-field cron syntax is used to configure schedules not only in Linux crontabs, but also in many CI/CD tools and container platforms, including GitHub Actions, GitLab CI, and Kubernetes CronJobs. It is a striking example of a syntax designed in the UNIX era still thriving unchanged in cloud-native environments.

One of the trickiest parts of cron syntax is how it behaves when both the day-of-month and day-of-week fields are set. It is tempting to assume an AND condition (a day satisfying both), but the actual specification is an OR condition (a day satisfying either), which is a common source of jobs running more often than intended.

Browse all trivia