Where are cron expressions used?

The same 5-field syntax appears in Linux and macOS crontab, GitHub Actions on.schedule, Kubernetes CronJob spec.schedule, AWS EventBridge cron rules (which add a year field), GCP Cloud Scheduler, Jenkins, Airflow and many hosted job runners. Learning one format therefore pays off across almost every platform, and this parser covers the common core that all of them share.

What do the fields and symbols in */5 * * * * mean?

The five fields are, from left to right, minute, hour, day of month, month and day of week. An asterisk matches every value, */5 matches every fifth value (every 5 minutes in the first position), 5-10 is an inclusive range, 1,3,5 is a list, and 1-5/2 steps through a range. Combining these operators lets you express nearly any recurring schedule.

Which numbers represent which weekdays?

In standard cron, 0 is Sunday, 1 is Monday, through 6 for Saturday. Some systems also accept 7 for Sunday, and Quartz numbers days 1 (Sunday) to 7 (Saturday) instead. This tool uses the standard 0-6 convention, which matches crontab, GitHub Actions and Kubernetes. Always confirm the convention of your scheduler when porting expressions between platforms.

How do I write "weekdays at 9 AM"?

Use 0 9 * * 1-5: minute 0, hour 9, any day of month, any month, Monday through Friday. Paste it into the tool and you will see "at 09:00 on weekdays" with the next run dates. For weekends only use 0 9 * * 0,6, and for Monday through Saturday use 0 9 * * 1-6.

What are the most common cron expressions?

Every minute is * * * * * (mainly for testing), top of every hour is 0 * * * *, every 5 minutes is */5 * * * *, daily at midnight is 0 0 * * *, weekdays at 09:00 is 0 9 * * 1-5, the first of every month is 0 0 1 * *, and every Sunday at midnight is 0 0 * * 0. All of these are available as one-click presets above the input.

Can I schedule something more often than once a minute?

Not with standard 5-field cron; the finest granularity is one minute. If you need seconds you must use a scheduler that supports it, such as Quartz with its 6-field format, EventBridge rate expressions, or an in-process timer in your application. For those cases this tool can still validate the 5-field portion of the schedule.

Does it work for GitHub Actions schedules?

Yes. GitHub Actions uses the standard 5-field syntax, evaluated in UTC. Keep in mind that scheduled workflows can start several minutes late during busy periods and that GitHub disables schedules on repositories with no activity for 60 days, so cron is not suitable when exact timing is critical.

How do I express "the last day of the month"?

Standard cron has no last-day specifier. The usual workaround is to run on 28,29,30,31 and have the script itself check whether tomorrow is the first of the month, for example with date -d tomorrow +%d. Quartz and some other extended implementations support an L specifier for this, but it is not part of the 5-field format this tool parses.

Which time zone are the run times shown in?

Run times are computed in your browser's local time zone. The server that actually runs the job uses its own zone, and containers and cloud runners default to UTC, so "09:00" in a crontab on a UTC host is 09:00 UTC, not local time. Use the Time Zone Converter to translate the schedule into the zone of your users or teammates before you commit it.

Is my data sent to a server?

No. Parsing and run-time calculation happen entirely in the browser. Nothing you enter leaves your machine, so you can safely inspect schedules for production systems, and you can even use the tool offline once the page has loaded. If the scheduled job itself calls an HTTP API, the cURL Converter can turn a tested curl command into the script code.

Cron Expression Parser

Decode any cron expression into plain English and list the next 5, 10 or 20 run times. Presets, field guide and validation. Runs entirely in your browser.

Cron syntax is compact but unforgiving: a single misplaced field turns a nightly backup into an hourly one. This parser explains what a 5-field expression actually means, shows the concrete upcoming run times in your local time zone, and highlights invalid fields so you can fix crontab, GitHub Actions and Kubernetes CronJob schedules before they go live.

// CRON EXPRESSION

Presets

Field guide

// Cron Expression Parser: Features

When a cron expression needs checking before it ships

Someone hands you a schedule like */15 8-18 * * 1-5 and asks whether it is right. You need a GitHub Actions workflow to run every Monday at 09:00. A Kubernetes CronJob should fire hourly but the pods never appear. A batch job silently stopped and you suspect the crontab line. In all of these cases the fastest check is to paste the expression here, read the plain-English description and compare the list of next run times against what you intended.

Plain-English explanation

The parser translates each expression into a readable sentence: */5 * * * * becomes "every 5 minutes", 0 9 * * 1-5 becomes "at 09:00 on weekdays", and 0 0 1 * * becomes "at 00:00 on day 1 of every month". The field guide below the input explains the five positions (minute, hour, day of month, month, day of week) and the operators * (any), */N (every N), N-M (range) and N,M (list), so the syntax is understandable even if you only touch cron a few times a year.

Upcoming run times

Descriptions can still hide surprises, so the tool also computes the next 5, 10 or 20 execution times from the current moment and lists them with the weekday. This makes it obvious whether "weekdays only" really excludes Saturday, whether a midnight job lands at 00:00 or 12:00, and whether day-of-month and day-of-week restrictions interact the way you expect. Times are calculated in your browser's local time zone.

Validation and error messages

Each field is checked against its allowed range (0-59, 0-23, 1-31, 1-12, 0-6). Out-of-range values, reversed ranges such as 10-5, zero or negative step values and expressions with the wrong number of fields all produce a specific error naming the offending field. The tool implements the standard 5-field format used by crontab, GitHub Actions and Kubernetes; it does not accept a seconds field, named months or weekdays such as JAN or MON, or the extended L, W and # specifiers found in Quartz and some enterprise schedulers.

Production job schedules stay on your machine

Parsing and scheduling calculations run entirely in your browser. The expressions you enter and the run times you see are never sent to a server, so it is safe to check production job schedules and internal batch timings here.

// Cron Expression Parser: FAQ

Where are cron expressions used?: The same 5-field syntax appears in Linux and macOS crontab, GitHub Actions on.schedule, Kubernetes CronJob spec.schedule, AWS EventBridge cron rules (which add a year field), GCP Cloud Scheduler, Jenkins, Airflow and many hosted job runners. Learning one format therefore pays off across almost every platform, and this parser covers the common core that all of them share.
What do the fields and symbols in */5 * * * * mean?: The five fields are, from left to right, minute, hour, day of month, month and day of week. An asterisk matches every value, */5 matches every fifth value (every 5 minutes in the first position), 5-10 is an inclusive range, 1,3,5 is a list, and 1-5/2 steps through a range. Combining these operators lets you express nearly any recurring schedule.
Which numbers represent which weekdays?: In standard cron, 0 is Sunday, 1 is Monday, through 6 for Saturday. Some systems also accept 7 for Sunday, and Quartz numbers days 1 (Sunday) to 7 (Saturday) instead. This tool uses the standard 0-6 convention, which matches crontab, GitHub Actions and Kubernetes. Always confirm the convention of your scheduler when porting expressions between platforms.
How do I write "weekdays at 9 AM"?: Use 0 9 * * 1-5: minute 0, hour 9, any day of month, any month, Monday through Friday. Paste it into the tool and you will see "at 09:00 on weekdays" with the next run dates. For weekends only use 0 9 * * 0,6, and for Monday through Saturday use 0 9 * * 1-6.
What are the most common cron expressions?: Every minute is * * * * * (mainly for testing), top of every hour is 0 * * * *, every 5 minutes is */5 * * * *, daily at midnight is 0 0 * * *, weekdays at 09:00 is 0 9 * * 1-5, the first of every month is 0 0 1 * *, and every Sunday at midnight is 0 0 * * 0. All of these are available as one-click presets above the input.
Can I schedule something more often than once a minute?: Not with standard 5-field cron; the finest granularity is one minute. If you need seconds you must use a scheduler that supports it, such as Quartz with its 6-field format, EventBridge rate expressions, or an in-process timer in your application. For those cases this tool can still validate the 5-field portion of the schedule.
Does it work for GitHub Actions schedules?: Yes. GitHub Actions uses the standard 5-field syntax, evaluated in UTC. Keep in mind that scheduled workflows can start several minutes late during busy periods and that GitHub disables schedules on repositories with no activity for 60 days, so cron is not suitable when exact timing is critical.
How do I express "the last day of the month"?: Standard cron has no last-day specifier. The usual workaround is to run on 28,29,30,31 and have the script itself check whether tomorrow is the first of the month, for example with date -d tomorrow +%d. Quartz and some other extended implementations support an L specifier for this, but it is not part of the 5-field format this tool parses.
Which time zone are the run times shown in?: Run times are computed in your browser's local time zone. The server that actually runs the job uses its own zone, and containers and cloud runners default to UTC, so "09:00" in a crontab on a UTC host is 09:00 UTC, not local time. Use the Time Zone Converter to translate the schedule into the zone of your users or teammates before you commit it.
Is my data sent to a server?: No. Parsing and run-time calculation happen entirely in the browser. Nothing you enter leaves your machine, so you can safely inspect schedules for production systems, and you can even use the tool offline once the page has loaded. If the scheduled job itself calls an HTTP API, the cURL Converter can turn a tested curl command into the script code.

// How to Use Cron Expression Parser

Enter a cron expression

Type a 5-field expression into the input or click one of the presets such as Every minute, Hourly, Daily, Weekdays 9:00 or Every 5 min. Starting from a preset and adjusting individual fields is usually faster than writing from scratch.
Read the description

The tool immediately shows a plain-English summary like "every 5 minutes" or "at 09:00 on weekdays". Click a field in the field guide to see its allowed range and operator rules. Invalid fields are reported with a specific error message.
Check the upcoming run times

Review the list of next execution times, switching between 5, 10 and 20 entries as needed. Compare the dates and weekdays against your intent before you paste the expression into crontab, a workflow file or a CronJob manifest.

Category Code