Cron Expression Generator
Build a cron schedule from simple fields and read it back in plain English, including the day-of-month and day-of-week rule that catches everyone once.
Presets:
—
A daily job at 02:30 runs 364 times a year
Cron fires on local wall-clock time, and twice a year the local wall clock is not a well-behaved sequence. Counting every firing of a daily job in New York across 2026:
| Scheduled at | Times it fires | What happens |
|---|---|---|
| 02:30 | 364 | never runs on 3/8 |
| 01:30 | 366 | runs twice on 11/1 |
| 03:30 | 365 | once a day, every day |
| 12:00 | 365 | once a day, every day |
On the spring-forward night the clock jumps straight from 01:59 to 03:00, so a job at 02:30 has no moment to run in and is skipped — silently, with nothing in any log to say it was due. On the autumn night the 01:00 hour happens twice, so a job at 01:30 runs twice, an hour apart, with the same date on both.
Neither is a bug in cron. Cron was asked to run at a wall-clock time, and the wall clock did what the wall clock does. The two failures are also opposites rather than the same mistake twice: one loses a run and the other gains one.
Which makes it a scheduling decision, not a code one
Sweeping all twenty-four hours shows how narrow the exposure is. Exactly 2 of them are affected — 01:30 and 02:30 — and every other hour fires exactly 365 times with no special handling at all.
So the cheapest fix is to move the job. Anything scheduled between 01:00 and 03:00 local is exposed; anything outside it is not. Overnight batch work gravitates to exactly that window because it feels like the quietest part of the night, which is why this bites so often.
If a job genuinely must run in that window, there are two honest options. Schedule it in UTC, where no transition ever happens — every hour is clean, which we check on each build. Or make it idempotent, so running twice is harmless and a skipped run is picked up by the next one. Both beat a job that is correct 363 days a year.
One thing worth knowing before you reach for it: setting CRON_TZ or
TZ inside a crontab is not portable. Several common cron implementations
ignore it entirely, and the job then runs on the machine's own zone while the crontab file
claims otherwise. That is worse than either behaviour on its own, because the file now documents
something untrue and the next person to read it has no reason to doubt it.
How to use
- Set the minute, hour, day, month and weekday fields.
- Read the plain-English description back.
- Check what it will actually do if you set both day fields.
- Confirm which timezone your scheduler uses.
Frequently asked questions
What are the five fields?
Minute, hour, day of month, month and day of week, in that order. Some systems add a seconds field at the front or a year at the end, which is why an expression copied from one scheduler can mean something different in another.
What happens if I set both day of month and day of week?
It runs on either, not both — the two day fields are combined with OR rather than AND. So a schedule set for the 1st and for Monday runs on every 1st and every Monday. This is the classic cron surprise and it is standard behaviour rather than a bug.
What does the slash mean?
A step. Every 15 minutes is written as a slash followed by 15 in the minute field, and it means every 15th value starting from the beginning of the range. Combined with a range, it steps within that range only.
Why did my job not run at the time I expected?
Most often a timezone difference between where you wrote the expression and where the scheduler runs — servers frequently run in UTC. Daylight saving is the other common cause, since a job scheduled in the skipped hour never fires and one in the repeated hour may fire twice.
Can cron run more often than once a minute?
Not in standard cron, whose finest granularity is one minute. Sub-minute scheduling needs a different mechanism — a long-running process, a systemd timer, or a job that sleeps internally. Trying to express seconds in a five-field expression simply does not work.
What is the difference between a question mark and an asterisk?
Quartz-style schedulers use a question mark to mean no specific value, required in one of the two day fields since they cannot both be specified. Standard Unix cron has no question mark at all, so an expression containing one will be rejected.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.