Cron example
Cron Every Second Tuesday of the Month
0 9 8-14 * 2At 09:00 AM, between day 8 and 14 of the month, and on Tuesday
Open in the cron expression generatorThe second Tuesday of a month is always somewhere between the 8th and the 14th, so the internet's favourite recipe restricts the day-of-month field to that range and the day-of-week field to Tuesday. On Quartz-style parsers that works. On classic Unix cron it does something else entirely, and this page is about that difference.
By NaveenKumar T · Updated · 5-field crontab expression
What each field means
| Field | Value | Meaning |
|---|---|---|
| Minute | 0 | Minute 0 |
| Hour | 9 | Hour 9 |
| Day of month | 8-14 | Days 8–14 |
| Month | * | Every month |
| Day of week | 2 | Tuesday |
Next 5 run times
Computing the next runs in your timezone…
Restricting both day fields means OR
Cron's five fields are normally ANDed together, with one documented exception. When both the day-of-month and the day-of-week fields are restricted — neither is an asterisk — Vixie cron and the POSIX specification run the command when either matches. So this expression fires at 9 AM on every date from the 8th to the 14th, and additionally on every Tuesday of the month: roughly eleven runs instead of one.
The next-run preview on this page is computed with the same OR semantics, so you can see the effect directly: consecutive dates appear in the list, which would be impossible if the fields were ANDed. Quartz, Spring and several cloud schedulers AND the two fields instead, which is why the recipe works for some people and fails silently for others.
The version that actually works
On classic cron, express the weekday in the schedule and the week number in the command. Schedule 0 9 * * 2 so cron fires every Tuesday, then guard the command with a date test that only lets the second one through: [ "$(date +%d)" -ge 08 ] && [ "$(date +%d)" -le 14 ] && /path/to/job. The day-of-month field stays an asterisk, so the OR rule never engages.
The mirror-image approach — 0 9 8-14 * * with a weekday guard on date +%u — works equally well and is easier to adapt to other rules, such as the last Friday or the third Wednesday. Either way, only one of the two day fields is restricted in the crontab itself, which is the invariant that keeps the semantics predictable.
Schedulers with native support
Quartz has a dedicated syntax for this: 0 0 9 ? * 3#2 means the second occurrence of weekday 3 in the month, with the question mark marking the day field as unspecified. Spring's scheduler, croner and several managed cloud schedulers implement the same hash notation. If your runtime is one of them, use it — it is unambiguous, and it removes the guard from your command entirely.
Before adopting either approach, decide what should happen in a month where the rule is ambiguous or the run is missed. Patch Tuesday jobs, board reporting and billing cycles all tend to acquire an exception within the first year, and a guard written in shell is much easier to extend than a clever cron expression nobody can read.
Build a variant of this schedule with dropdowns and check the next ten runs before you install it.
Open the cron generatorRelated cron examples
Browse every schedule on the cron expression generator, read the cron expression syntax guide for the rules behind the five fields, or the developer tools guides for the longer explanations.