What time zone are the run times in?

Your browser's local time zone, taken from your operating system. Real cron daemons run in the server's time zone — usually UTC in cloud environments. If your server's clock differs from yours, the schedule will fire at a different wall-clock moment than the one shown here.

Does this support seconds (6-field cron)?

No. The tool implements standard Unix cron (5 fields). Six-field expressions with leading seconds are a Quartz scheduler extension used by Spring, Jenkins, and some Java tools. If you paste a 6-field expression you'll see a 'expected 5 fields' error.

Are 'L', 'W', '#', and '?' supported?

No. Those are Quartz extensions ('L' = last day, 'W' = nearest weekday, '#' = nth weekday, '?' = no specific value). Standard Unix cron, Kubernetes CronJob, and GitHub Actions don't accept them either. Stick to *, integers, ranges, lists, and steps.

What happens when day-of-month and day-of-week are both set?

Standard Unix cron treats them as OR: the job runs whenever EITHER field matches. So '0 0 1 * 1' fires on the 1st of the month AND on every Monday — not only on Mondays that fall on the 1st. The preview here follows that rule.

What does '*/15' actually mean?

It's a step value: starting from the field's minimum, fire every 15 units. For minutes that's 0, 15, 30, 45. For hours that's 0, 6, 12, 18, 24 — but 24 wraps so you get 0, 6, 12, 18. You can also combine with ranges: '0-30/5' fires at 0, 5, 10, 15, 20, 25, 30.

Why does my schedule look slightly off after daylight saving changes?

Cron operates on local wall-clock time. On the 'spring forward' day, a 02:30 job is skipped (02:00 jumps to 03:00). On 'fall back', a 01:30 job may run twice. Run critical schedules in UTC to avoid this — the underlying Unix epoch (see our Unix timestamp glossary entry) doesn't observe DST.

How do I express 'every weekday at 9am'?

Use '0 9 * * 1-5'. Days of week are 0 (Sunday) through 6 (Saturday); 7 is also accepted as Sunday in some implementations but is non-portable, so we recommend 0.

Cron Expression Generator & Parser

Type a cron expression — see what it means and when it next runs.

Buğra SözeriDeveloper

Published May 30, 2026

A cron expression is a five-field schedule string used by Unix cron, Kubernetes CronJob, GitHub Actions, GitLab CI, and most job runners. The fields are minute, hour, day-of-month, month, day-of-week. The generator below parses your expression locally, describes it in plain English, and shows the next five times it will fire in your browser’s time zone.

All parsing happens in your browser. Convertitive never logs or transmits the expressions you test. Times are computed against your machine’s clock — if your server runs in UTC (most do), expect the production runs to differ from the preview here.

Cron expression (minute hour day month weekday)

Presets:

Plain English

Every 15 minutes, on Monday, Tuesday, Wednesday, Thursday, and Friday.

Next 5 runs (your local time)

Computing…

Field	Token	Matches
minute	*/15	0, 15, 30, 45
hour	*	every hour (24)
day of month	*	every day of month (31)
month	*	every month (12)
day of week	1-5	1, 2, 3, 4, 5

How to use

Type or pick an expression
Enter a five-field expression like '*/15 * * * 1-5', or choose a preset from the dropdown (hourly, daily, weekly, weekdays, etc.). Each field accepts *, integers, ranges (1-5), lists (1,3,5), and steps (*/15).
Read the plain-English description
The tool translates the expression into a sentence (e.g. 'At 09:00 on Monday') so you can sanity-check before deploying. Wrong field order is the most common cron bug — the description catches it instantly.
Verify the next 5 runs
Run times are computed from your machine's local time. To verify behaviour on a UTC server, mentally add or subtract your UTC offset, or change your system clock briefly to test edge cases like month rollover.
Copy and paste into your runner
Use the copy button on the next-runs card to grab the schedule for documentation, or copy the expression itself into your crontab, Kubernetes CronJob spec, or CI workflow file.

Common patterns

Expression	Meaning
* * * * *	Every minute.
/5 * * *	Every 5 minutes (00, 05, 10, …).
0 * * * *	Top of every hour. Equivalent to `@hourly`.
0 9 * * 1-5	09:00 Monday through Friday.
0 0 * * 0	Midnight every Sunday. Equivalent to `@weekly`.
0 0 1 * *	Midnight on the 1st of every month. `@monthly`.
15 10 * * 1,3,5	10:15 every Monday, Wednesday, Friday.
0 /6 * *	Every 6 hours (00:00, 06:00, 12:00, 18:00).

Frequently asked questions

What time zone are the run times in?: Your browser's local time zone, taken from your operating system. Real cron daemons run in the server's time zone — usually UTC in cloud environments. If your server's clock differs from yours, the schedule will fire at a different wall-clock moment than the one shown here.
Does this support seconds (6-field cron)?: No. The tool implements standard Unix cron (5 fields). Six-field expressions with leading seconds are a Quartz scheduler extension used by Spring, Jenkins, and some Java tools. If you paste a 6-field expression you'll see a 'expected 5 fields' error.
Are 'L', 'W', '#', and '?' supported?: No. Those are Quartz extensions ('L' = last day, 'W' = nearest weekday, '#' = nth weekday, '?' = no specific value). Standard Unix cron, Kubernetes CronJob, and GitHub Actions don't accept them either. Stick to *, integers, ranges, lists, and steps.
What happens when day-of-month and day-of-week are both set?: Standard Unix cron treats them as OR: the job runs whenever EITHER field matches. So '0 0 1 * 1' fires on the 1st of the month AND on every Monday — not only on Mondays that fall on the 1st. The preview here follows that rule.
What does '*/15' actually mean?: It's a step value: starting from the field's minimum, fire every 15 units. For minutes that's 0, 15, 30, 45. For hours that's 0, 6, 12, 18, 24 — but 24 wraps so you get 0, 6, 12, 18. You can also combine with ranges: '0-30/5' fires at 0, 5, 10, 15, 20, 25, 30.
Why does my schedule look slightly off after daylight saving changes?: Cron operates on local wall-clock time. On the 'spring forward' day, a 02:30 job is skipped (02:00 jumps to 03:00). On 'fall back', a 01:30 job may run twice. Run critical schedules in UTC to avoid this — the underlying Unix epoch (see our Unix timestamp glossary entry) doesn't observe DST.
How do I express 'every weekday at 9am'?: Use '0 9 * * 1-5'. Days of week are 0 (Sunday) through 6 (Saturday); 7 is also accepted as Sunday in some implementations but is non-portable, so we recommend 0.

About

Field reference

The five fields, in order: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC), day of week (0-6 or SUN-SAT, with 0 = Sunday). Each accepts an asterisk (any value), a single integer, a comma list (1,3,5), a range (1-5), a step on a wildcard (*/15) or a range (1-30/5). Names like MON or JAN are case-insensitive.

Where cron lives today

The classic Vixie cron still runs on most Linux servers, but the syntax has spread far beyond /etc/crontab. Kubernetes 'CronJob' resources, GitHub Actions and GitLab CI 'schedule' triggers, AWS EventBridge rate/cron rules, Vercel/Netlify cron jobs, Hangfire, Quartz, and most job-queue libraries all parse the same five-field grammar. Knowing standard cron makes the schedule portable across every one of them.

Time-zone gotchas

Cron has no built-in concept of time zones — it just reads the local clock. That means a schedule moves with daylight-saving transitions: the same '0 9 * * *' fires at a different UTC offset in summer vs. winter. For predictable distributed schedules, run cron in UTC (most Linux servers do) and convert in your head, or use a runner that explicitly accepts a TZ field. Our Unix timestamp tool is handy for sanity-checking actual fire times.

Day-of-month vs. day-of-week

When both fields are restricted (neither is '*'), Unix cron uses OR logic: a run fires when EITHER matches. This trips up nearly every cron user at least once. To restrict to 'Mondays that fall on the 1st', you need application-level logic — the cron field grammar can't express AND between the two day fields.

Sources & references

Authoritative references behind the math, constants, and tables on this page. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.

POSIX crontab(5) — IEEE Std 1003.1 — Canonical 5-field grammar (minute hour dom month dow), range/list/step semantics, and the OR rule when both day fields are restricted.(as of 2026-05-30)
Vixie cron — crontab(5) man page — Most-deployed implementation; documents the @hourly/@daily/@weekly/@monthly/@yearly shorthand presets surfaced in the dropdown.(as of 2026-05-30)
Kubernetes CronJob — schedule syntax — Reference used for what subset of cron is portable to modern runners (5-field, no Quartz extensions).(as of 2026-05-30)

Related guide

From “* * * * *” to step values, ranges, and the Quartz-vs-POSIX quirks that bite on the wrong scheduler — the cron tutorial walks each field with worked schedules you can copy.

Read: Cron expression tutorial →

Related tools & reading

Unix timestamp
Seconds since 1970-01-01 UTC — the time base every cron daemon measures from underneath the wall clock.
IANA time zone
Why “America/New_York” is safer than “EST” for any schedule that crosses daylight saving.
UUID generator
Need unique IDs to tag each scheduled run? Generate v4 / v7 UUIDs here.
JWT decoder
Inspect the exp/iat claims of tokens your scheduled jobs hand around.