Cron expression explainer
Read what an expression means, then check when it actually fires. Runs in your browser — no account, nothing sent anywhere.
In plain English
At 09:00 AM, Monday through Friday
Closest two runs are 1 day apart.
Next runs in UTC
- Fri 11 Sept, 09:00next
- Mon 14 Sept, 09:00+3 days
- Tue 15 Sept, 09:00+1 day
- Wed 16 Sept, 09:00+1 day
- Thu 17 Sept, 09:00+1 day
- Fri 18 Sept, 09:00+1 day
Times are shown in UTC, and account for daylight saving changes in that zone.
The five fields
A standard cron expression has five fields, separated by spaces:
| Position | Field | Range |
|---|---|---|
| 1 | Minute | 0–59 |
| 2 | Hour | 0–23 |
| 3 | Day of month | 1–31 |
| 4 | Month | 1–12 |
| 5 | Day of week | 0–6, Sunday is 0 |
Within a field, * means every value, */5 means every fifth, 1-5 is a range and 1,15 is a list.
Day of month and day of week are an OR, not an AND
The single most surprising rule in cron. If you set both fields, most implementations run the job 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 the month, and every Monday”, which is roughly five times as often as intended.
To get the intersection you have to check the date inside your job. There is no cron syntax for it.
Daylight saving, and the run that moves
Cron fires on wall-clock time, and twice a year the wall clock lies. When a zone springs forward from 02:00 to 03:00, the time 02:30 does not exist that day. When it falls back, 02:30 happens twice.
What a scheduler does about that is not standardised, and that is the part worth knowing: some skip the run, some fire it at the next valid moment, some fire it twice on the way back. See it for yourself — set the timezone to America/New_York, the expression to 30 2 * * 0, and the start date to 10 March 2027. That run lands at 03:30 rather than 02:30, because 02:30 was never on the clock.
An hour late is the good outcome. Whether your own scheduler agrees with this preview is a question about your scheduler — which is exactly why a job that must run once a day is better scheduled in UTC, or at least outside 01:00–03:00 local, where the question never comes up.
Questions
What does * * * * * mean in cron?
Every minute. Five asterisks is “every value in every field” — minute, hour, day of month, month, day of week — which resolves to once a minute, the smallest interval standard cron can express.
Are cron times in local time or UTC?
Whichever clock the scheduler keeps. Classic crontab uses the server’s local time; hosted schedulers usually let you pick a timezone per job. For a job that must run exactly once a day, prefer UTC — local time crosses daylight saving twice a year, and that is where once-a-day quietly becomes zero or twice.
Why does my cron expression have six fields?
It is from a scheduler with an extended syntax. Quartz and Spring put a seconds field first; AWS EventBridge appends a year field. Standard five-field cron tools will reject either, so trim the extra field — or keep the expression with the system it was written for.
Can cron run a job every 30 seconds?
Not in standard cron — a minute is the floor. The classic workaround is two entries with a sleep 30 in one of them; schedulers with a seconds field, or a service with sub-minute plans, express it directly.
Running one of these for real
An expression is the easy part. The rest is somewhere to run it from, a retry when your endpoint is briefly down, and a way to find out it stopped firing that is not a customer telling you. That is what getNodi does — it calls your URL on this schedule, records every run, and tells you when one fails. The free plan runs hourly jobs and needs no card.
If your schedule is for Vercel, check it against the Hobby limits first — Vercel rejects several expressions that are valid everywhere else.