Crontab expression generator

The five fields

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

Within a field, * means every value, */n means every nth, a-b is a range and commas separate a list. So 0,30 9-17 * * 1-5 is “on the hour and half hour, between 9am and 5pm, Monday to Friday”.

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

When both fields are restricted, cron runs the job when either matches — not both. 0 0 13 * 5 therefore fires on every 13th of the month and on every Friday, which is roughly 60 times a year rather than once or twice.

This is documented behaviour inherited from Vixie cron and it surprises almost everyone. If you genuinely need an AND, schedule the broader condition and test the narrower one in the command: 0 0 13 * * [ "$(date +\%u)" = 5 ] && /path/to/job. The description above the builder spells out which rule is in force for your expression.

Timezones

cron uses the machine's local timezone unless told otherwise, and that is the origin of most “it ran an hour early” incidents. Two further hazards during daylight-saving transitions: a job scheduled inside the hour that is skipped in spring may not run at all, and one inside the repeated hour in autumn may run twice.

Robust options, in order of preference: run the server in UTC and convert in your head; set CRON_TZ=Europe/London at the top of the crontab where your cron supports it; or use a systemd timer with Persistent=true, which also catches up after downtime. The timezone selector above shows the next ten runs in whichever zone you choose, so you can preview the difference before committing.

Special strings

Why a correct expression still fails

Nine times out of ten the schedule was never the problem. cron runs your command with an almost empty environment:

• PATH is minimal — typically /usr/bin:/bin. Use absolute paths for the interpreter and the script: /usr/bin/python3 /opt/app/job.py.
• No shell profile is sourced, so nothing from .bashrc or .profile exists — including virtualenv activation, nvm and any exported credentials.
• The working directory is the user's home, not the script's location. Use absolute paths for data files too, or cd first.
• A bare % is a newline in crontab syntax and must be escaped as \%. This bites hardest with date +%Y-%m-%d.
• Output goes to email. If mail is not configured the output is simply lost. Redirect it: >> /var/log/job.log 2>&1.

Testing a job

Run it the way cron will, rather than the way your shell does: env -i /bin/sh -c '/full/path/to/command' strips your environment and reproduces most cron-only failures immediately. Then check the schedule with the next-run table above, and only then install it with crontab -e.

Quartz is a different syntax

Java schedulers — Quartz, Spring's @Scheduled, Jenkins in some configurations — use six or seven fields with seconds at the front, require ? in whichever of day-of-month or day-of-week is unconstrained, and number weekdays 1–7 starting at Sunday. Quartz mode above adds the seconds field; the run times are still computed with Unix semantics, so treat them as a guide rather than gospel for Quartz.