Cron biweekly - every other week pattern

Trigger at least daily in UTC and run when the persisted UTC due timestamp has passed; after success, advance it by 1,209,600 seconds. A weekly local-time trigger cannot guarantee the exact interval because spring DST can make the check skip until the following week.

The cron trigger still fires weekly, every Monday at 09:00, not every other Monday. The wrapper makes alternate invocations exit without doing the work. Expression: 0 9 * * 1

Gate the weekly trigger with week=$(date +%V); ((10#$week % 2 == 0)) || exit 0. ISO week 53 can create consecutive selected Mondays or a three-week gap, so a parity wrapper is unsuitable when the interval must always be exactly 14 days.

Yes. A 09:00 local-time schedule stays at 09:00, but the elapsed gap across a DST change is 335 or 337 hours instead of 336. Use UTC when exact elapsed timing matters.

Use cron(0 9 ? * MON *) in EventBridge, then apply the alternating-week check in the target. EventBridge has no native biweekly operator. Expression: 0 9 ? * MON *

Use 0 0 9 ? * MON to trigger every Monday at 09:00, then gate alternate weeks in the job. Quartz adds seconds first and still cannot represent an exact every-other-week interval. Expression: 0 0 9 ? * MON

Yes, but schedule the workflow weekly and skip alternate runs in a step. GitHub Actions uses UTC by default, supports an optional IANA timezone, and its five-minute minimum does not restrict a weekly trigger.

Yes. Vercel Hobby permits schedules no more frequent than once per day, so a weekly trigger is allowed; Vercel cron uses UTC, and the endpoint must perform the alternating-week check.

Store the next UTC due timestamp in durable, shared storage such as the job database. A local file is safe only on one persistent host; ephemeral or horizontally scaled workers can lose it or race.

Lock before reading the UTC due timestamp, and advance it only after successful work. This prevents concurrent daily checks from both running and keeps a failed attempt eligible for retry.

Yes. You can run the weekly HTTP trigger on Crontap with retries, while the endpoint keeps the ISO-week or persisted-timestamp gate that cron itself cannot express.

0 9 * * 1, plus a wrapper. The cron still fires weekly. A wrapper must skip alternate runs; for an exact 14-day interval, trigger at least daily in UTC and persist the next UTC due timestamp. Paste the expression into Linux crontab, Vercel cron, node-cron, or robfig/cron; AWS EventBridge and Quartz need the six-field form.

The editor above shows the next 30+ runs on a calendar in your local timezone, plus a plain-English description. If the calendar matches your intent, the cron is correct.

Linux crontab, Vercel cron jobs, node-cron, robfig/cron, and Kubernetes CronJob accept the five-field form as is. AWS EventBridge and Quartz use six-field expressions with a ? in one of the day fields; see the AWS and Quartz guides for the conversion. Vercel's free Hobby plan caps the minimum frequency at once-per-day; the Pro plan removes that cap.

Most schedulers will start the new run anyway, leading to overlap. To prevent this, wrap the command with flock -n /tmp/myjob.lock /path/to/script.sh on Linux, or set concurrencyPolicy: Forbid on Kubernetes CronJob. Vercel and EventBridge may overlap runs if the previous one is still executing; make the handler idempotent.