Every Other Week

There is no cron expression for “every other week.” That is not a gap in a particular implementation — it follows from what a cron expression is.

Every field in a cron expression is a set of values matched against the current wall clock. The scheduler wakes up, asks “does now match?”, and fires if it does. There is no counter, no record of the previous firing, and therefore no way to express “the second Monday since the last time this ran.” Fortnightly is a statement about intervals between runs; cron only speaks about positions on the calendar.

The trap: 0 0 */14 * *

This is the expression almost everyone tries, and it is wrong in a specific, reproducible way.

The day-of-month field runs 1 to 31. The step syntax */14 means “start at the field minimum and keep adding 14 while still in range”: day 1, day 15, day 29, then 43 — out of range, so it stops. At the start of the next month the field resets to 1 and the same three values repeat.

So the actual schedule is the 1st, 15th and 29th of every month:

Jan  1 ──14d──▶ Jan 15 ──14d──▶ Jan 29 ──3d──▶ Feb  1 ──14d──▶ Feb 15 ...

Two clean fortnights, then a two- or three-day stub where the month boundary cuts the cycle short. Over a year that comes to 35 runs — eleven months contributing three each, plus two in February — against the 26 a real fortnightly schedule produces. The expression over-fires by about a third, and the runs land on wildly uneven gaps.

Leap years are worse

In a leap year February has a 29th, so the third firing happens — and then the counter resets for March:

2028-02-15 ──14d──▶ 2028-02-29 ──1d──▶ 2028-03-01

Two runs one day apart. Any job that assumes at least a fortnight of separation — a billing run, a digest email, an on-call handover — will double-process that boundary. The leap-year total is 36.

This is the same failure as every 45 minutes and every 45 seconds: a step that doesn’t divide its field evenly, so the schedule only looks periodic until the field wraps. The difference is that the day-of-month field wraps at a variable point — 28, 29, 30 or 31 — so the error isn’t even consistent month to month.

The other wrong answer

In Quartz idiom you’ll sometimes see 0 0 0 ? * 1/2 offered for “every other week.” That fires on Sunday, Tuesday, Thursday and Saturday — Quartz numbers day-of-week 1–7 starting at Sunday, so the /2 step walks across days inside a single week, not across weeks. It is four runs a week, not one every two.

What actually works: weekly plus a parity gate

Schedule the job weekly with an ordinary cron expression, and let the job decide whether this week counts:

0 9 * * 1 /usr/local/bin/fortnightly.sh

#!/bin/sh
# Weeks elapsed since the Unix epoch, mod 2.
[ $(( ($(date -u +%s) / 604800) % 2 )) -eq 0 ] || exit 0
# ... the real work ...

The scheduling stays in cron where it belongs, and the “every other” part lives in one line of shell. Consecutive Mondays are exactly 604,800 seconds apart, so the counter increments by exactly one each week and the parity alternates without fail. Flip -eq 0 to -eq 1 to shift onto the opposite week.

Don’t use ISO week numbers for this

The gate you’ll find most often on the web uses the ISO week number instead:

# DON'T — breaks at some year boundaries.
[ $(( $(date +%V) % 2 )) -eq 0 ] || exit 0

ISO 8601 years have 53 weeks whenever January 1 falls on a Thursday, or on a Wednesday in a leap year. In those years week 53 is followed by week 01 — two odd numbers back to back — and a job gated on even weeks simply waits an extra fortnight:

2026-12-07  (W50)  fires
2026-12-21  (W52)  fires
2027-01-11  (W02)  fires   ← 21 days later, not 14
2027-01-25  (W04)  fires

2026 is a 53-week year, so this is live right now, not a theoretical edge case. The epoch-based counter holds a clean 14-day gap across the same boundary. It anchors to a fixed instant rather than to a calendar that occasionally has an extra week in it.

One honest caveat: date -u +%s is absolute epoch seconds, so if your crontab runs in a local timezone that observes DST, two consecutive firings are 604,800 ± 3,600 seconds apart. That can only flip the parity if a firing lands within an hour of an epoch-week boundary — which falls on Thursday 00:00 UTC, because the Unix epoch itself began on a Thursday. Schedule the job in UTC, or on any day other than Thursday, and it cannot bite.

The alternative: stop asking for fortnightly

Most teams who ask for “every other week” want a predictable rhythm, not a mathematically exact 14-day gap. If that describes you, the 1st and 15th is a plain cron expression with no gating logic at all:

0 0 1,15 * * /usr/local/bin/semimonthly.sh

That’s semi-monthly, not fortnightly — 24 runs a year on fixed dates, with gaps between 13 and 17 days. For billing, payroll and invoicing that is usually the better fit anyway, because finance cares which date the run happened on, not how many days elapsed since the last one.

Schedulers that can express it directly

If you can move the schedule out of cron entirely, several runtimes handle a fortnightly interval natively:

• APScheduler — IntervalTrigger(weeks=2), which sidesteps CronTrigger’s field rules completely. See the APScheduler guide.
• Spring — @Scheduled(fixedRate = 1_209_600_000L). Note that this counts from application start rather than the calendar, so a redeploy resets the phase. See the Spring @Scheduled guide.
• Quartz — a SimpleTrigger with a 336-hour repeat interval. CronTrigger cannot do it; see the Quartz dialect reference.
• systemd — an OnUnitActiveSec=2w timer, which is monotonic and needs no calendar arithmetic. See systemd timers.

Each of these expresses an interval, which is what fortnightly actually is. Reach back for cron only when the runs need to land on specific calendar positions — and at that point you’re describing the 1st and 15th, not every other week.