Cron Expression Explainer and Next Run Times Calculator

How to use the Cron Expression Explainer and Next Run Times Calculator

1. Type or paste the expressionEnter the expression in the box. The page detects the system from the number of fields and the symbols used. If you know better, open the settings and choose the system yourself.
2. Read the plain-English summaryThe summary at the top says what the schedule means, and the fields underneath are labeled so you can see which number is the minute, the hour, and so on.
3. Check the next run timesChoose the time zone the job runs in and look at the list. Each run shows the local time, the UTC time, and how far away it is. You can start the list from a date in the future to look at a specific week.
4. Read the warningsIf the expression has a common problem, such as a day that does not exist in some months or two day fields combined in a surprising way, it is listed under Things to check.
5. Copy it for another systemThe last section writes the same schedule in the syntax of the other systems. Copy the one you need. Where a schedule cannot be written in another system, the tool says why.

How a cron expression is read

A classic Unix cron expression has five fields separated by spaces: minute (0 to 59), hour (0 to 23), day of the month (1 to 31), month (1 to 12), and day of the week (0 to 7, where both 0 and 7 mean Sunday). The job runs at every moment when all five fields match the clock. This is the format described in the crontab(5) manual page.

Each field can hold a single value, a list such as 1,15, a range such as 9-17, a step such as */15 for every 15, or a combination such as 0-30/10. A star means every value. Month and weekday names such as JAN and MON are accepted. A step with a star starts at the first value of the field, so */15 in the minute field means 0, 15, 30, and 45.

• * means every value of the field.
• , separates a list of values.
• - makes a range, and ranges are inclusive.
• / makes a step, as in */5 or 10-40/10.
• @daily, @hourly, @weekly, @monthly, and @yearly are shortcuts in Unix cron, and Spring accepts them too.

The four dialects and where they differ

Quartz, the Java scheduler, uses six or seven fields: seconds first, then minute, hour, day of month, month, day of week, and an optional year. Spring's CronExpression also has six fields starting with seconds, but no year. AWS EventBridge rules use six fields without seconds but with a year: minutes, hours, day of month, month, day of week, and year, written inside cron( ).

The most common mistake when moving between them is the day of the week. In Unix cron and in Spring, 0 or 7 is Sunday and 1 is Monday. In Quartz and AWS EventBridge, 1 is Sunday and 7 is Saturday. An expression with 1-5 at the end therefore means Monday to Friday in one system and Sunday to Thursday in the other. Day names such as MON-FRI mean the same thing everywhere, so they are the safe way to write it.

Quartz and AWS add special characters that Unix cron does not have. L means the last day, so L in the day-of-month field is the last day of the month and 6L in the weekday field of Quartz is the last Friday of the month. W finds the nearest weekday to a date, and 3#2 means the second occurrence of a weekday in the month. Quartz and AWS also use a question mark in one of the two day fields to say that it should be ignored, because they do not allow both to be set at once. Spring documents L, W, and # as well.

The day-of-month and day-of-week trap

In Unix cron, the two day fields interact in a way that surprises almost everyone. The crontab(5) manual says that if both fields are restricted, which means neither starts with a star, the command runs when either field matches. So 0 9 1 * 1 does not mean 09:00 on the first of the month if it is a Monday. It means 09:00 on the first of every month and also on every Monday.

If you want only a Monday that falls on a certain date, cron cannot express it. The usual workaround is to schedule the job for every Monday and test the date inside the command. This tool shows a warning when you write an expression that combines the two fields, and its summary says that the days are combined with or.

A related detail is that the crontab(5) rule looks at whether the field starts with a star. Because of this, an expression with */2 in the day-of-month field and a specific weekday is treated as restricted only by the weekday. Other cron programs treat it differently, so the tool adds a note when you write it.

Time zones and daylight saving time

A cron expression has no time zone. It is read against a clock, and which clock depends on the scheduler: the server's local time for a classic cron daemon, UTC for many cloud schedulers, and a zone you can set in others. GitHub Actions, for example, runs the schedule event in UTC by default and lets you add a time zone as an IANA name. Pick the zone your scheduler uses and the run times are calculated for it.

When clocks change, two things can happen to a job at a fixed local time. If clocks move forward, an hour does not exist, and a job set to 02:30 that night has no 02:30 to run at. If clocks move back, an hour happens twice, and the job can run twice. The crontab(5) manual says exactly that: times that do not exist never match, and times that happen more than once match more than once. The cron(8) page of cronie describes a different behavior: a skipped job runs immediately after the change and a repeated job is not run twice, for jobs at a fixed time. GitHub's documentation says that scheduled workflows in skipped hours advance to the next valid time.

Because the rules differ, the safest approach is to avoid the hours around the change, or to schedule in UTC. The run list on this page follows the plain reading of the clock, and the daylight saving section lists every run of your schedule in the next year that lands in a gap or a repeated hour, so you know whether your job is affected at all.

Mistakes the tool warns about

Some expressions are valid but almost never what the author meant. The tool checks for the most common ones and tells you in plain words.

• A schedule that never runs, such as the 30th of February, or the 31st in a list of months that all have 30 days.
• A day like the 31st that exists only in some of the chosen months, so the job silently skips the others.
• A star in the minute field combined with a specific hour, as in * 3 * * *, which runs 60 times in that hour and not once.
• A step that does not divide the range evenly, such as */7 in the minute field, where the last gap in each hour is shorter than the others.
• Both day fields set in Unix cron, which combines them with or.
• Weekday numbers in Quartz or AWS, which start at Sunday as 1, with a note on what the numbers mean.
• A schedule that runs more often than the scheduler allows, such as faster than every 5 minutes on GitHub Actions.

Converting between systems

The conversion section rewrites the schedule in each dialect. It adds a zero seconds field when going to Quartz or Spring, drops it when going to Unix or AWS, adds a question mark to the day field where Quartz and AWS need one, and replaces weekday numbers with names so that the numbering difference cannot cause a mistake.

Some conversions are impossible, and the tool says so instead of guessing. A schedule that runs every 10 seconds cannot be written in Unix cron, which has no seconds field. A schedule that uses the last day of the month cannot be written in Unix cron either. Quartz and AWS have day patterns that Unix cron lacks, and Unix cron has a macro syntax that Quartz and AWS lack. The tool names each reason.

Writing a schedule with the builder

If you do not know the syntax, open the builder, choose how often the job runs, and fill in the time, the days, or the date. The builder writes a Unix cron expression and the page explains it, so you can learn the syntax from the result. Use the expression you have built in the main box and change it from there.

Limits and accuracy

• Run times follow the standard rules of each dialect. A particular scheduler may add its own behavior, such as a delay, a jitter, or a different treatment of daylight saving time, and this page cannot know your scheduler's settings.
• Daylight saving behavior differs between cron programs. The run list shows the plain reading of the clock, and the page lists the affected runs so you can check your scheduler's documentation.
• Unix cron programs differ in small details, such as how they treat */n in a day field and whether they accept names in ranges. The tool follows the crontab(5) manual page.
• Spring's rule for combining the day-of-month and day-of-week fields is not documented clearly, so the tool refuses expressions that set both rather than guess.
• The tool searches up to twelve years ahead. A schedule that does not match any date in that time is reported as never running.
• Time zone names come from your browser. A name your browser does not know is reported, and you can use UTC or another name instead.

Frequently asked questions