Cron generator that shows the next five runs

Monday, in crontab. The day-of-week field counts from 0 for Sunday, so 1 is Monday, 5 is Friday and both 0 and 7 mean Sunday. The trap is that Quartz — used by Spring, Jenkins and Elastic — numbers the same field from 1 for Sunday, which makes 1 mean Sunday and shifts every literal by a day when an expression is copied between the two. Writing MON instead of 1 sidesteps the whole question, and both grammars accept the names.

Because cron ORs the two day fields instead of ANDing them. When both day-of-month and day-of-week are restricted, the job runs on days that match either one — so 0 0 1 * 1 fires on the 1st of every month and on every Monday, about 57 times a year rather than 12. The rule comes from the POSIX specification and is honoured by Vixie cron, so it is not a quirk of any one implementation. If you need the intersection, restrict one field in cron and test the other inside the job: run daily at midnight on Mondays, and exit early unless the date is the 1st.

Whatever the machine or the scheduler decides, and almost never the one you meant. A classic crontab uses the system time zone unless a CRON_TZ= line appears above the entry; systemd timers take OnCalendar with an explicit zone; a Kubernetes CronJob runs in the controller's zone, which is normally UTC, unless spec.timeZone is set — a field that only became stable in Kubernetes 1.27; and GitHub Actions schedules are UTC with no option to change them. Pick the zone in the panel above to see what your expression actually does on that clock.

It depends on whether the wall-clock time exists that day. When the clocks go forward, the skipped hour never occurs, and Vixie cron runs jobs scheduled inside it once, immediately after the jump; when they go back, the repeated hour would fire a job twice, and cron suppresses the second occurrence for fixed-time entries. Jobs that run more often than once an hour — anything with a wildcard or a step in the hour field — are left alone entirely and simply follow the clock. The schedule above marks a run whose wall-clock time is skipped, and the safe answer for anything financial is to schedule in UTC.

It is valid, and it does not mean every seven minutes. A step divides the field's own range from its start, so */7 in the minute field gives 0, 7, 14, 21, 28, 35, 42, 49 and 56 — and then the hour rolls over, putting only four minutes between the last run and the next. The same applies to any step that does not divide the range evenly: */40 fires at minute 0 and minute 40 and nowhere else. Steps that divide 60 cleanly — 2, 3, 4, 5, 6, 10, 12, 15, 20, 30 — are the only ones that produce an even spacing.

The sixth field is seconds, and it goes at the front. Standard crontab, Kubernetes CronJobs and GitHub Actions all take exactly five fields — minute, hour, day of month, month, day of week — and reject anything longer. Spring, node-cron, Quartz and several job frameworks accept a leading seconds field, so 0 30 9 * * 1-5 in those systems is 09:30 on weekdays and would be an error in a crontab. Quartz also allows a seventh field for the year. Use the toggle above to add or drop the seconds field and watch the description change; the warning bar tells you when an expression would not be accepted by a plain crontab.

Cron starts another copy — it tracks schedules, not processes. Two backups writing to one file, or two importers reading one queue, is a failure mode that only appears once the job gets slow in production. The standard fix on Linux is flock, as in flock -n /tmp/job.lock /usr/local/bin/job.sh, which makes the second run exit immediately. Kubernetes has this built in as spec.concurrencyPolicy, where Forbid skips the new run and Replace kills the old one, and it also has startingDeadlineSeconds to control what happens after the controller has been down through a scheduled window.