Processed entirely on your device — nothing is uploaded
How to use the cron expression parser
- 1Type or paste a five-field cron expression.
- 2Read the plain-English description below.
- 3Check the next five firing times against what you expected.
- 4Use the presets as a starting point for common schedules.
Five fields, and the order matters
A standard cron expression has five fields separated by spaces: minute, hour, day of month, month, and day of week. Getting the order wrong is the most common mistake, and it fails silently — the job simply runs at a time nobody expected.
Minutes run 0 to 59 and hours 0 to 23, so there is no midday/midnight ambiguity: 0 is midnight and 12 is noon. Day of month is 1 to 31, month 1 to 12, and day of week 0 to 6 with Sunday as 0. Many implementations also accept 7 for Sunday and three-letter names for months and days, both of which are understood here.
Within a field, `*` means every value, a comma lists values, a hyphen gives a range, and a slash adds a step. So `*/15` in the minute field means every fifteenth minute, and `1-5` in day of week means Monday to Friday.
Note that some systems add a sixth field for seconds at the front — Quartz and Spring do this — and a few add a year at the end. A five-field expression pasted into a six-field system runs at the wrong time. Check which dialect your scheduler expects.
The day-of-month and day-of-week trap
This is the behaviour that surprises almost everyone, and it is worth understanding because it produces jobs that run far more often than intended.
When both the day-of-month and day-of-week fields are restricted — neither is `*` — cron fires when **either** matches, not both. So `0 0 1 * 1` does not mean "the first of the month, if it is a Monday". It means "the first of every month, and also every Monday", which is roughly five times as often.
To get an AND, you cannot use cron alone. The usual approach is to schedule on one of the two and check the other in the job itself — run every Monday, and exit immediately unless the date is also the first.
The tool flags this whenever both fields are restricted, and the next-runs list makes it visible: if you see dates you did not expect, this is almost always why.
Time zones, which cron does not really have
A cron expression carries no time zone. It is interpreted in whatever zone the scheduler runs in, which on a server is usually UTC and on a laptop is local time. The same expression therefore fires at different wall-clock times depending on where it runs — a frequent source of "it worked in staging" reports.
Daylight saving is worse. When clocks go forward, an hour disappears: a job scheduled for 02:30 simply does not run that day in most implementations. When clocks go back, that hour repeats, and a job scheduled inside it may run twice.
The pragmatic advice is to run schedulers in UTC and to avoid scheduling anything important between 01:00 and 03:00 local time. If a job must run at a particular local time year-round, use a scheduler with explicit time-zone support rather than trying to express it in cron.
The next-run times shown here are in your browser's local zone, which is convenient for checking but is not necessarily the zone your server will use.
Schedules worth knowing
`*/5 * * * *` every five minutes, the standard for health checks and short polling. `0 * * * *` hourly on the hour. `0 9 * * 1-5` weekday mornings, the classic business-hours report.
`0 0 * * 0` weekly at midnight on Sunday, and `0 3 1 * *` monthly at 3am on the first — a common slot for heavy maintenance because it is quiet.
Shorthand aliases exist and are clearer when they fit: `@daily`, `@hourly`, `@weekly`, `@monthly` and `@yearly` are understood by most schedulers and by this parser.
One piece of operational advice: avoid scheduling on the hour if you can. Everything in the world runs at `0 * * * *`, so external APIs are busiest exactly then. Shifting to `7 * * * *` costs nothing and avoids the crowd.
Frequently asked questions
What are the five fields?
Minute (0–59), hour (0–23), day of month (1–31), month (1–12), day of week (0–6, Sunday is 0). Some schedulers add a seconds field at the front.
Does `0 0 1 * 1` mean the first of the month if it is a Monday?
No. When both day fields are restricted, cron fires when either matches — so that runs on the 1st and on every Monday. Check the second condition inside your job.
What time zone does cron use?
Whatever the scheduler runs in — usually UTC on a server, local time on a laptop. Expressions carry no zone of their own.
What happens during daylight saving?
A job scheduled in the hour that is skipped forward usually does not run at all; one in the repeated hour may run twice. Avoid scheduling between 01:00 and 03:00 local.
What does */15 mean?
Every fifteenth value in that field. In the minute field, that is minutes 0, 15, 30 and 45.
Are @daily and @hourly supported?
Yes, along with @hourly, @weekly, @monthly and @yearly. They are clearer than the numeric equivalents when they fit.