Cron Expression Simulator
Type a cron expression and see the next runs as real dates and times, in any timezone. Why */7 is not every 7 minutes, why day-of-month and day-of-week are OR and not AND, what happens to a job scheduled in the hour daylight saving deletes, and which expressions never fire at all. The parser and the schedule are real and run in your browser.
Category: DevOps
What You Will Learn
- What the five fields are, and why a sixth one means you are not writing plain cron
- Why `*/7` is not every 7 minutes, and where the short gap appears
- Why day-of-month and day-of-week are OR and not AND, and the daily job that creates
- What `0 0 * * *` does that `* * * * *` does not
- How `@daily`, `@weekly` and the other macros expand, and where they are not supported
- What happens to a 01:30 job on the night the clock goes forward, and on the night it goes back
- Why the same expression fires at different moments in different timezones
- Which expressions are valid, accepted, and then never fire at all
- Why `L`, `W` and `#` work in some schedulers and not in cron
- How to read a schedule as dates rather than as five fields
Topics covered: cron, linux, scheduling, automation, timezones, debugging, educational, interactive
// simulator
Cron Expression Simulator
Type a cron expression and see the next runs as real dates and times, in any timezone. Why */7 is not every 7 minutes, why day-of-month and day-of-week are OR and not AND, what happens to a job scheduled in the hour daylight saving deletes, and which expressions never fire at all. The parser and the schedule are real and run in your browser.
minutes of the hour60 of 60
hours of the day24 of 24
days of the month31 of 31
About this cron expression simulator
What you'll learn
- That the useful answer is a list of dates, not a description of five fields
- That cron matches a clock rather than counting an interval forward, which is why steps can be uneven
- That the two day fields combine with OR, the mistake that turns a monthly job into a weekly one
- That daylight saving deletes an hour once a year and repeats one once a year, and your job is in it
How it works
- The parser and the schedule are real and run in your browser. Nothing here is a canned answer.
- Change the timezone and the same expression moves, because the expression was never absolute.
- Set the start date, or jump straight to the next clock change, to watch a transition happen.
- Type your own expression. It is treated exactly like the examples.
The behaviour here follows crontab(5), which is the Vixie cron most Linux systems ship. One detail is worth knowing before you rely on it: daylight saving is the part where implementations genuinely differ. This simulator shows the plain wall-clock reading, where a time that does not exist does not fire and a time that happens twice fires twice. Vixie cron special-cases some of that, and systemd timers do not behave like cron at all. If a job must not be skipped or doubled, schedule it in UTC or keep it away from the small hours.
Related: the YAML parsing simulator for the other thing that reads your config differently from how you wrote it, and the Linux terminal simulator for where crontabs live.
Overview
A cron expression is five fields: minute, hour, day of month, month and day of week. They look simple, and most cron bugs come from a few rules that are easy to forget. This simulator parses any expression you type and lists when it will actually fire next, in the timezone you choose, so arguments about a schedule can be settled by looking. Two grids show which minutes and hours are lit, which is how you see that */7 in the minute field fires at minutes 0, 7, 14 and so on up to 56, then again at 0, so the gap across the top of the hour is shorter than the rest. The examples cover the other traps. When both day of month and day of week are restricted, cron runs when either matches, not both. A job scheduled during a daylight saving change can be skipped or run twice. A date like 30 February never comes. And * * * * * runs 1,440 times a day, which is rarely what someone meant.
Try this
- Type */7 * * * * and look at the minute grid to see why the interval before the top of the hour is shorter than the others.
- Load "The OR trap" (0 9 1 * MON) and check the next runs to see it fire on the 1st and on every Monday.
- Load the job at 30 1 * * * in Europe/London and find the date when daylight saving makes it skip a run and the date when it runs twice.
Frequently asked questions
- What does */5 mean in a cron expression?
- It is a step: every 5th value of that field, starting from its first value. In the minute field, */5 means minutes 0, 5, 10 and so on up to 55.
- Why does my cron job run on extra days?
- If you restrict both day of month and day of week, classic cron runs the job when either one matches. 0 9 1 * MON runs at 09:00 on the 1st of every month and also on every Monday.
- Which timezone does cron use?
- Usually the timezone of the machine or scheduler running it, which is often UTC on servers and containers. Some schedulers, such as Kubernetes CronJobs, let you set a timezone per job.
Try next
// simulator
Preview Environment Simulator
See how a pull request becomes a temporary copy of your app, complete with a private URL, safe test data, review checks, and automatic cleanup.
// game
Heroku-Style Name Generator
Generate names the way Heroku, Docker, Kubernetes, and petname do, see how the word lists combine, and learn when the birthday problem makes random names collide.
// simulator
How Docker Works Under the Hood
Watch what really happens when you run docker run -p 8080:80 nginx, one layer at a time. Step down the whole stack: the CLI, the daemon, the registry pull, containerd, the OCI runtime bundle, runc, the running container, and the shared Linux kernel. Every stage shows the real low-level command you can run yourself, so it doubles as a tour of the primitives that make a container: namespaces, cgroups, and runc. A container is not a small VM, and this shows you why.