Cron Simulator — see when your cron job will actually run

How to read a cron expression

┌───────────── minute        0–59
│ ┌─────────── hour          0–23
│ │ ┌───────── day of month  1–31
│ │ │ ┌─────── month         1–12  or JAN–DEC
│ │ │ │ ┌───── day of week   0–7   or SUN–SAT  (0 and 7 are both Sunday)
│ │ │ │ │
* * * * *   command to run

Every cron expression is five fields separated by spaces, read left to right from the smallest unit to the largest. Each field takes * for "every value", a single number, a list such as 1,3,5, a range such as 1-5, or a step such as */15 meaning "every 15th value". The job fires on any minute where all five fields match — with one important exception covered in the next section. So 30 2 * * 1-5 reads as minute 30, hour 2, any day of month, any month, days of week Monday through Friday: 2:30 AM on weekdays.

The day-of-month / day-of-week OR trap

Here is the rule that surprises nearly everyone. When both the day-of-month and the day-of-week fields are restricted — neither one is * — cron combines them with OR, not AND. It is not a bug; it is the documented behaviour of Vixie cron and the crontab on essentially every Linux box.

So 0 0 13 * 5 does not mean "midnight on Friday the 13th". It means "midnight on every 13th of the month, and also midnight on every Friday" — around 64 runs a year instead of the one or two you wanted. When only one of the two fields is restricted, the intuitive AND behaviour applies. To get a true AND, put one constraint in cron and check the other inside the job: schedule 0 0 13 * *, then exit early unless date +%u returns 5. The simulator flags this trap whenever your expression hits it, and the run list above shows you both patterns interleaved.

How daylight saving time breaks cron jobs

Cron matches wall-clock time, and twice a year the wall clock lies. On the spring-forward date, an hour is deleted: in America/Chicago, 2:00 AM jumps straight to 3:00 AM, so a job scheduled at 30 2 * * * has no 2:30 AM to fire at and is silently skipped that day. No error, no log line, just a missing run that someone notices a week later.

On the fall-back date the opposite happens: an hour repeats, so 1:30 AM occurs twice and a job scheduled in that window may run twice. Behaviour differs by scheduler — Vixie cron tries to de-duplicate, but container schedulers and application-level cron libraries frequently do not. The reliable fix is to avoid scheduling anything between 1:00 and 3:00 AM local time, or to run the scheduler on a UTC clock, which has no transitions at all. Switch the timezone picker above to your server's zone and the simulator scans the next 12 months for both hazards using your browser's own timezone database.

Cron and timezones

A cron expression carries no timezone. It is interpreted in the system timezone of whatever machine runs it, and on cloud servers, CI runners, and Docker images that is almost always UTC. This is why 0 9 * * * deployed from a laptop in Berlin fires at 10 AM or 11 AM local, depending on the season, and why the offset moves by an hour twice a year without anyone touching the crontab.

Some schedulers let you pin a zone per job — a CRON_TZ= prefix in the crontab, a TZ setting, or a timezone field in a managed cron product. If yours does not, the honest options are to write your schedules in UTC and accept the local drift, or to schedule at a wall-clock hour where the drift does not matter. This cron timezone converter evaluates your expression in the zone you pick — the wall-clock times a server in that zone would fire at — and shows the matching UTC instants alongside, so you can see both views of the same schedule at once.

Frequently asked questions about cron