# Cron Expression Generator & Explainer

Paste a cron expression to read it in plain English and see exactly when it runs next in your time zone — or build one from simple choices. Every field is expanded so you can check the schedule yourself.

- Runs in your browser
- Next runs in any time zone
- Field-by-field breakdown
- Standard 5-field cron

## Quick answer

The cron expression `*/15 9-17 * * 1-5` runs **every 15 minutes from 9:00 to 17:45, Monday to Friday**: 4 times an hour for 9 hours, so 36 runs each weekday. Standard cron has five fields — minute, hour, day of month, month, day of week — as defined for `crontab` in the POSIX standard.

## About the Cron Expression Generator & Explainer

A cron expression is one line of five fields — minute, hour, day of month, month and day of week — that tells a scheduler when to run a job. It is compact and easy to get subtly wrong: a value in the wrong field, a weekday numbered from the other end of the week, or a server on UTC while you think in Eastern time.

In **Explain** mode, paste an expression from a crontab, a Kubernetes CronJob or a CI pipeline to get a plain-English description, every field expanded into the exact values it matches, and the next run times in your scheduler's time zone. In **Build** mode, pick a pattern and the page writes the expression, shows how each choice became a field and explains the result back. Everything runs in your browser.

## How to use it

In **Explain** mode, type or paste an expression such as `*/15 9-17 * * 1-5`. Five fields are standard; six are read as seconds first, and nicknames such as `@daily` are expanded. Results update as you type, and an invalid expression is highlighted with the reason.

Switch to **Build** when you know the schedule but not the syntax. Choose how often the job runs — every N minutes, hourly, daily, on chosen weekdays or monthly — and fill in the fields that appear. Hours use the 24-hour clock, so 6:30 PM is hour 18, minute 30\. **Show the math** lists how each choice became a field.

Under _Next run times_, enter the time zone your scheduler runs in and how many runs to list, up to 20\. When the expression suits them, the results include a crontab line and a Kubernetes spec with copy buttons, and _Copy link_ saves your inputs in the address for a teammate.

## Use cases

- **Reviewing a pull request.** Confirm that a new CronJob's "weekday mornings" really means Monday to Friday at 9:00 in the cluster's zone, not 9:00 UTC.
- **Debugging a job that ran at the wrong time.** Compare runs in local time and UTC to spot an offset or a daylight saving shift.
- **Catching the day-of-month trap.** See at once when a schedule that sets both a date and a weekday runs on far more days than intended.
- **Moving a job between schedulers.** Check a Quartz or AWS-style expression after removing the fields standard cron lacks, and see where weekday numbering differs.

## How a cron expression is read

Left to right, the fields are minute, hour, day of month, month and day of week. A job runs at every minute where all five match, with one exception for the two day fields, covered below. Here is `0,30 9-17 * */3 1-5`, which uses each kind of value standard cron allows:

| Field        | Allowed values                    | Example | Matches                           |
| ------------ | --------------------------------- | ------- | --------------------------------- |
| Minute       | 0–59                              | 0,30    | 0, 30                             |
| Hour         | 0–23                              | 9-17    | 9, 10, 11, 12, 13, 14, 15, 16, 17 |
| Day of month | 1–31                              | \*      | every day of the month            |
| Month        | 1–12 or JAN–DEC                   | \*/3    | Jan, Apr, Jul, Oct                |
| Day of week  | 0–7 or SUN–SAT (0 and 7 = Sunday) | 1-5     | Mon, Tue, Wed, Thu, Fri           |

Together it reads: At 0 and 30 minutes past the hour, between 09:00 AM and 05:59 PM, Monday through Friday, every 3 months. Four characters do the work:

- `*` matches every allowed value.
- `,` separates a list: `0,30` is on the hour and at half past.
- `-` is an inclusive range: `9-17` includes the 5 PM hour, so `0,30 9-17` last runs at 5:30 PM.
- `/` adds a step: `*/15` is every 15th value from the lowest, and `10-50/20` in the minute field is 10, 30, 50.

Months and weekdays also accept three-letter names such as `JAN` or `MON`. Day of week runs from 0 to 7, and both 0 and 7 mean Sunday, so `1-5` is Monday through Friday; Kubernetes is stricter and accepts only 0 to 6\. Some older crontabs accept a name only on its own, not in a range or list, so numbers are the most portable.

Steps start over at the end of each cycle. `*/7` in the minute field matches 0, 7, 14, 21, 28, 35, 42, 49, 56; the next match is :00 of the following hour, only 4 minutes after :56\. Likewise `0 */5 * * *` runs at 0, 5, 10, 15, 20 o'clock and again at midnight, 4 hours later. The results flag these uneven gaps. For minutes, only 1, 2, 3, 4, 5, 6, 10, 12, 15, 20 and 30 divide the hour evenly.

## The day-of-month OR day-of-week rule

When both day fields are restricted — neither is `*` — standard cron runs the job on days that match _either_ field. `0 0 13 * 5` looks like "midnight on Friday the 13th", but from Thu, Oct 8, 2026, 12:00 PM UTC its next runs are:

1. Fri, Oct 9, 2026, 12:00 AM UTC
2. Tue, Oct 13, 2026, 12:00 AM UTC
3. Fri, Oct 16, 2026, 12:00 AM UTC
4. Fri, Oct 23, 2026, 12:00 AM UTC
5. Fri, Oct 30, 2026, 12:00 AM UTC

That is every Friday plus every 13th. Standard cron cannot say "only when both match"; schedule on one field and test the other inside the command instead — run every Friday and exit unless the date is the 13th. Quartz and AWS avoid the problem by requiring `?` in one of the two fields.

One edge case: in Vixie cron and its descendants, a day field that merely _starts_ with an asterisk, such as `*/2`, counts as unrestricted, so there `0 0 */2 * 1` means odd-numbered days that are also Mondays. This tool treats anything other than a bare `*` as restricted, so confirm such schedules on the machine that runs them.

## Nicknames

Most cron daemons accept these shortcuts in place of the five fields, and the tool expands them:

| Nickname  | Same as       | Runs                                                |
| --------- | ------------- | --------------------------------------------------- |
| @yearly   | 0 0 1 1 \*    | At 12:00 AM, on day 1 of the month, only in January |
| @annually | 0 0 1 1 \*    | At 12:00 AM, on day 1 of the month, only in January |
| @monthly  | 0 0 1 \* \*   | At 12:00 AM, on day 1 of the month                  |
| @weekly   | 0 0 \* \* 0   | At 12:00 AM, only on Sunday                         |
| @daily    | 0 0 \* \* \*  | At 12:00 AM                                         |
| @midnight | 0 0 \* \* \*  | At 12:00 AM                                         |
| @hourly   | 0 \* \* \* \* | Every hour                                          |

`@reboot` runs once when the cron daemon starts. It is not a schedule, so the tool rejects it. So does `@every 5m`, from Go's robfig/cron: it repeats at a fixed interval counted from when the scheduler started, not at set clock times, so it has no fields to expand.

## Worked examples

**Every 15 minutes in business hours.** `*/15 9-17 * * 1-5` in America/New\_York reads: Every 15 minutes, between 09:00 AM and 05:59 PM, Monday through Friday. From Thu, Oct 8, 2026, 8:00 AM EDT, the first runs are Thu, Oct 8, 2026, 9:00 AM EDT; Thu, Oct 8, 2026, 9:15 AM EDT; Thu, Oct 8, 2026, 9:30 AM EDT. The last run each weekday is 5:45 PM, because the hour range includes 17 and the minute field allows :45.

**Built: Monday, Wednesday and Friday at 6:30 PM.** Choose _On days of the week_, tick the three days and enter hour 18, minute 30\. The builder writes `30 18 * * 1,3,5` — minute 30, hour 18, weekdays 1,3,5\. In America/Chicago the next runs are Fri, Oct 9, 2026, 6:30 PM CDT; Mon, Oct 12, 2026, 6:30 PM CDT; Wed, Oct 14, 2026, 6:30 PM CDT.

**Once a month on the 31st.** `0 0 31 * *` next runs Sat, Oct 31, 2026, 12:00 AM UTC; Thu, Dec 31, 2026, 12:00 AM UTC; Sun, Jan 31, 2027, 12:00 AM UTC; Wed, Mar 31, 2027, 12:00 AM UTC. November and February are missing because they have no 31st; cron skips such months rather than moving the run to the last day.

## Quartz, Kubernetes and AWS EventBridge

Several schedulers say "cron" but mean slightly different things. This tool reads standard five-field cron and the six-field variant with seconds first.

| Feature             | Standard cron       | Quartz                     | Kubernetes CronJob | AWS EventBridge                      |
| ------------------- | ------------------- | -------------------------- | ------------------ | ------------------------------------ |
| Fields              | 5                   | 6 or 7                     | 5                  | 6                                    |
| Seconds             | No                  | First field                | No                 | No                                   |
| Year                | No                  | Optional, last             | No                 | Required, last                       |
| Sunday is           | 0 or 7              | 1                          | 0 (7 is rejected)  | 1                                    |
| Both day fields set | Either matches      | Not allowed; one must be ? | Either matches     | Not allowed; one must be ?           |
| Time zone           | The machine's clock | Set on the trigger         | timeZone field     | UTC for rules; Scheduler can set one |

**Quartz** puts seconds first and allows a trailing year. It numbers weekdays 1 to 7 from Sunday, so a Quartz `2` is Monday while a cron `2` is Tuesday; names avoid the mix-up. One day field must be `?` ("no specific value"). A six-field expression such as `0 30 9 ? * MON-FRI` works here as is and reads "At 09:30 AM, Monday through Friday"; drop the year from a seven-field one.

**Kubernetes CronJob** takes standard five-field cron and the nicknames in `spec.schedule`, with two restrictions: day of week runs 0 to 6 only, so `7` and ranges such as `1-7` fail validation, and the extensions `L`, `W` and `#` are not supported. Set `spec.timeZone` to an IANA name (a stable field since Kubernetes 1.27); otherwise the schedule follows the kube-controller-manager's zone. `CRON_TZ=` or `TZ=` inside the schedule is not supported, and current versions reject it.

**AWS EventBridge** writes `cron(minutes hours day-of-month month day-of-week year)`: no seconds, a year at the end, one day field set to `?`, and weekdays 1 to 7 from Sunday. Scheduled rules run in UTC; EventBridge Scheduler can attach a time zone. To check one here, drop the year and change `?` to `*`: `0 18 ? * MON-FRI *` becomes `0 18 * * MON-FRI`. Paste it as is, with or without the `cron( )` wrapper, and the tool suggests that conversion instead of misreading the first field as seconds.

AWS and Quartz also write steps with a starting number, such as `0/15` for "every 15 minutes from :00". Standard cron spells that `*/15`, or a range with a step such as `5-59/15` when the start is not the lowest value, and some implementations reject the short form. The suggested conversion rewrites it, so `0/15 * ? * MON-FRI *` becomes `*/15 * * * MON-FRI`. In a five- or six-field expression the tool makes the same change on its own: `0/15 * * * *` is checked as `*/15 * * * *`, with a note saying so.

## Time zones and daylight saving time

Classic cron has no time zone field: it follows the clock of the machine it runs on, usually UTC for servers and containers. Some daemons accept a `CRON_TZ=` line in the crontab, and Go's robfig/cron reads a prefix on the schedule itself, as in `CRON_TZ=America/New_York 0 9 * * *`; paste that form and the tool lists the runs in the prefixed zone. Otherwise, set the time zone field above to whatever your scheduler really uses; the [time zone converter](https://17x7.com/tools/time-zone-converter/) turns "9 AM in Chicago" into UTC hours.

Daylight saving time skips or repeats an hour. For `30 2 * * *` in America/New\_York, 2:30 AM does not exist the morning clocks jump forward in March, so the tool lists Sun, Mar 14, 2027, 3:30 AM EDT, then Mon, Mar 15, 2027, 2:30 AM EDT. When clocks fall back in November, the repeated hour is listed once: from just before 1 AM, `*/30 * * * *` lists 1:00 AM EDT, 1:30 AM EDT, 2:00 AM EST and 2:30 AM EST.

Vixie cron and cronie treat the two kinds of job differently. A job at a fixed time that falls in the skipped hour runs soon after the jump, and one in the repeated hour is not run a second time. A job with `*` in the minute or hour field simply follows the new clock, so it skips the spring-forward gap and runs again during the repeated fall-back hour. Other schedulers have their own rules, so jobs that must run exactly once a day are safest outside 1–3 AM local time, or on UTC.

## Limits of this tool

- It reads five-field cron and six fields with seconds first. Seven-field Quartz and AWS expressions need converting; the tool says how.
- It also accepts the extensions `L`, `W` and `#`, which plain crontab and Kubernetes reject, so no ready-to-paste lines are offered for them.
- Run times come from the calendar alone. A job still running, a host that was down or a Kubernetes `concurrencyPolicy` can delay or skip real runs.
- The plain-English sentence is generated; for unusual combinations, trust the field table.

## Sources

- [The Open Group — POSIX crontab utility](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/crontab.html) — checked 2026-10-10

## Frequently asked questions

What does \*/5 mean in a cron expression?

Every fifth value of the field, counting from its lowest value. In the minute field, `*/5` matches 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, so `*/5 * * * *` runs every five minutes. A range can take a step too: `0-30/10` is 0, 10, 20, 30.

What is the cron expression for every weekday at 9 AM?

`0 9 * * 1-5`: minute 0, hour 9, any day of the month, any month, days 1 through 5 (Monday to Friday). On a UTC server that is 9 AM UTC — 4 or 5 AM in New York, depending on daylight saving time — so check the scheduler's time zone.

Why does my cron job run on days I didn't expect?

Usually the OR rule: with both day of month and day of week set, the job runs on days matching either, so `0 0 13 * 5` fires every Friday and every 13th. Other causes are weekday numbers copied from Quartz or AWS, where 2 is Monday, and a server time zone that pushes evening runs past midnight.

How do I run a cron job on the last day of the month?

Standard crontab has no symbol for it. Run on days 28 to 31 and exit unless tomorrow is the 1st: `0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /path/to/command` with GNU date. The % is escaped because crontab turns a bare % into a newline. Quartz, AWS and some libraries accept `L` in the day-of-month field.

Can cron run a job every 90 minutes?

Not with one line, because minute steps restart every hour. Two lines do it: `0 0-21/3 * * *` runs on the hour at 0, 3, 6, 9, 12, 15, 18, 21, and `30 1-22/3 * * *` at half past 1, 4, 7, 10, 13, 16, 19, 22 — sixteen runs a day, 90 minutes apart.

Are 0 and 7 both Sunday in cron?

In standard cron (Vixie cron, cronie and their descendants), yes: the day-of-week field accepts 0 to 7 and both ends mean Sunday, so `1-7` matches every day of the week (all 7). Kubernetes CronJob accepts only 0 to 6 and rejects 7, so write Sunday as 0 or SUN there; this page leaves out the Kubernetes snippet when the field uses 7 and shows the replacement. Quartz and AWS EventBridge count 1 to 7 with 1 as Sunday.

Is my cron expression sent anywhere?

No. The description, field table and run times are computed in your browser, and typing makes no network request; your inputs are only copied into the address bar so the link can be shared. Scripts and AI agents can call the same explainer as a JSON API or MCP tool — see the [developer page](https://17x7.com/developers/).

**Disclaimer.** Run times follow standard cron rules in the time zone you choose; real schedulers differ in details such as daylight saving handling, the day-field OR rule and extensions like L and #, so confirm critical schedules on the system that will run them.

Last updated October 15, 2026. Found a mistake? [Tell us](https://17x7.com/contact/) — corrections ship the same week.

---

Source: https://17x7.com/tools/cron-expression/ · Last updated: 2026-10-15