The 5-field cron format
A standard cron expression is five whitespace-separated fields. Read left to right, they answer “at what minute, at what hour, on which day”:
| Position | Field | Allowed values | Special characters |
|---|---|---|---|
| 1 | Minute | 0–59 | * , - / |
| 2 | Hour | 0–23 | * , - / |
| 3 | Day of month | 1–31 | * , - / |
| 4 | Month | 1–12 or JAN–DEC | * , - / |
| 5 | Day of week | 0–7 or SUN–SAT (0 and 7 are both Sunday) | * , - / |
A leading sixth field is interpreted as seconds (0–59), the convention used by Quartz and Node’s node-cron. This tool detects that case and tells you it did.
Macros
Instead of five fields you can use a shortcut: @yearly (or @annually), @monthly, @weekly, @daily (or @midnight), and @hourly. @reboot means “once at start-up” and has no clock schedule, so it is rejected here.
Special characters
| Character | Meaning | Example | Supported here |
|---|---|---|---|
* | Every value in the field | * * * * * | Yes |
, | A list of values | 0 0 1,15 * * | Yes |
- | An inclusive range | 0 9-17 * * * | Yes |
/ | A step, on its own (*/15) or over a range (0-30/5) | */15 * * * * | Yes |
? | “No specific value” (Quartz) | 0 0 1 * ? | Accepted, treated as * |
L | Last day of month or week (Quartz) | 0 0 L * * | No |
# | The nth weekday of the month (Quartz) | 0 0 * * 5#3 | No |
W | Nearest weekday to a date (Quartz) | 0 0 15W * * | No |
Common expressions
| Expression | Runs |
|---|---|
* * * * * | Every minute |
*/5 * * * * | Every 5 minutes |
0 * * * * | Every hour, on the hour |
0 0 * * * | Every day at midnight |
0 9 * * 1-5 | 09:00 AM, Monday through Friday |
0 0 * * 0 | Midnight every Sunday |
0 0 1 * * | Midnight on the 1st of every month |
30 8 1,15 * * | 08:30 AM on the 1st and 15th |
0 */6 * * * | Every 6 hours (00:00, 06:00, 12:00, 18:00) |
0 0 1 1 * | Midnight on 1 January |
The 0-versus-7 Sunday ambiguity
The day-of-week field runs 0 (Sunday) to 6 (Saturday). Because a range such as 1-7 would otherwise be impossible, almost every cron implementation also accepts 7 as Sunday — so 0 and 7 mean the same day. Watch for the off-by-one when you come from a language where the week starts on Monday: 3 is Wednesday here, not Tuesday. Named values SUN, MON, … SAT avoid the confusion entirely.
One more trap: when both the day-of-month and day-of-week fields are set to something other than *, standard cron runs the job when either matches. 0 0 13 * 5 fires on the 13th and on every Friday, not only on Friday the 13th.
Timezones and daylight saving
The run times here use your browser’s local timezone (shown above the list). A cron daemon uses the server’s timezone unless a CRON_TZ or TZ line overrides it, and servers commonly run in UTC — so a 0 9 * * * job on a UTC box is a 9am-UTC job, not 9am where you are.
Around a daylight-saving change the arithmetic gets slippery. If the clock jumps forward over the scheduled hour, some cron implementations run the job once anyway and some skip it; if the clock falls back, a fixed-hour job can run twice. The list below is computed with the local clock and is a planning aid, not a guarantee, across a DST boundary.
Questions
When both the day fields are set, which wins?
Neither — standard cron runs the job when the day-of-month or the day-of-week matches. This parser follows that OR rule. If one field is *, only the other applies.
Is 0 Sunday, or is 7?
Both. 0 is Sunday and 6 is Saturday; 7 is also accepted as Sunday. Names SUN–SAT work too.
What timezone are the next runs in?
Your browser’s local timezone, displayed above the list. Real cron uses the server timezone or the crontab’s CRON_TZ/TZ — check which before trusting the hour.
Does it handle seconds or Quartz syntax?
A 6-field expression is parsed with the first field as seconds, and the tool says so. The Quartz characters L, W and # are not supported; ? is treated as *.
Do the run times handle daylight saving?
They are computed with the local clock, so a DST change inside the window can make a fixed-hour job look like it skips or repeats an hour. Treat the list as a guide near a clock change.