Convert Unix cron (POSIX/Vixie) to AWS EventBridge
Translate crontab expressions to EventBridge cron() format: the year field, Sunday renumbering (0→1), the mandatory ? token, and UTC evaluation — with verified examples.
About this conversion
EventBridge looks like Unix cron with one extra field, and that resemblance is exactly what bites. The sixth field is year — not seconds, which is the near-universal first guess. Sunday is 1, not 0, so numeric weekday values all shift. And EventBridge enforces a rule Unix cron never had: exactly one of day-of-month or day-of-week must be ?, which is why a pasted five-field expression with two real day fields gets rejected — or worse, hand-"fixed" into the wrong schedule.
What changes in this conversion
- The expression gains a sixth field (year, defaulting to *) and is wrapped in the cron( … ) form the EventBridge API expects.
- Numeric day-of-week values shift up by one (Sunday 0 → 1, weekdays 1-5 → 2-6). Name tokens are unchanged.
- Exactly one of day-of-month / day-of-week must be ? — the converter inserts it on the unrestricted side. cron(* * * * * *) is invalid in EventBridge for this reason.
- Schedules are evaluated in UTC unless you set the EventBridge Scheduler timezone field — the expression converts, but double-check what wall-clock time you meant.
Worked examples
0 9 * * 1-5converts tocron(0 9 ? * 2-6 *)lossless*/5 * * * *converts tocron(*/5 * * * ? *)lossless0 0 1 1 *converts tocron(0 0 1 1 ? *)lossless0 0 1-7 * 1converts tocron(0 0 1-7 * ? *)lossy- ⚠ POSIX fires when day-of-month OR day-of-week matches; AWS EventBridge requires one — kept day-of-month (1-7), dropped day-of-week (1).
Every converted expression above is produced by the same conversion engine the tool uses — generated and integrity-tested, not hand-written.
Lossy and refused conversions
The lossy case is the POSIX day-field union: an expression restricting both day-of-month and day-of-week fires on either match under POSIX rules, and EventBridge's mandatory ? makes that union unstatable. The converter keeps day-of-month, drops day-of-week, and flags it. If the intent was an nth-weekday schedule ("first Monday"), EventBridge supports Quartz-style # tokens natively — 2#1 in the day-of-week field — which is usually what the POSIX expression was approximating in the first place.
FAQ
Is the sixth EventBridge field seconds?
No — it's year. EventBridge has no seconds support at all; jobs fire at second 0. The extra-field-means-seconds assumption is the most common EventBridge cron misread.
Why does EventBridge reject my expression when both day fields are set?
EventBridge requires exactly one of day-of-month or day-of-week to be ?. Unix cron allows both to be restricted (firing on either match) — that union has no EventBridge equivalent, so one side has to give.