Convert AWS EventBridge to Unix cron (POSIX/Vixie)
Translate EventBridge cron() and rate() expressions to POSIX/Vixie crontab format: unwrapping cron(), dropping the year field, Sunday renumbering (1→0), and rate() caveats.
About this conversion
Migrating schedules off EventBridge — to a container crontab, a VM, or any Vixie-style scheduler — means unwinding three AWS-specific things. The cron( … ) wrapper goes away. The year field goes away, and if it carried a real constraint, that constraint is gone with it, because no crontab can express "only in 2027". And numeric day-of-week values shift down by one, since EventBridge counts Sunday as 1 where Unix counts it as 0. rate() expressions are a fourth wrinkle with no crontab counterpart at all.
What changes in this conversion
- The cron( … ) wrapper is removed and the year field dropped, leaving the five POSIX fields.
- Numeric day-of-week values shift down by one (EventBridge 2-6 → Unix 1-5). Name tokens pass through.
- ? becomes * — Unix cron has no don't-care token, and no rule that demands one.
- rate(…) expressions are synthesized into cron fields: rate(1 minute) maps exactly to * * * * *; coarser rates are approximated on clock boundaries.
- A crontab runs in the system's local time (or TZ/CRON_TZ where supported) — EventBridge evaluated in UTC, so the effective wall-clock time can move even though the expression converted cleanly.
Worked examples
cron(0 9 ? * 2-6 *)converts to0 9 * * 1-5losslessrate(1 minute)converts to* * * * *losslessrate(5 minutes)converts to*/5 * * * *lossy- ⚠ rate() is a rolling interval from the rule's start time; the cron form fires on clock boundaries instead.
cron(0 12 * * ? 2027)converts to0 12 * * *lossy- ⚠ POSIX has no year field — the year constraint (2027) is dropped.
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
Two conversions in this direction are flagged rather than silent. A constrained year field (cron(0 12 * * ? 2027)) is dropped — the crontab fires every year, and the converter says so. And rate() beyond one minute is a rolling interval measured from the rule's start time, while the cron form fires on clock boundaries: rate(5 minutes) becomes */5 * * * *, which is the same cadence but not necessarily the same instants. L/W/# calendar tokens, if present, refuse to convert entirely — a five-field crontab cannot express them.
FAQ
What happens to my rate(5 minutes) schedule?
It becomes */5 * * * * — same frequency, different instants. rate() counts from when the rule was created; cron fires at minutes 0, 5, 10… The converter flags this so a monitoring check expecting the old timestamps doesn't page you.
Can a crontab run a schedule only in a specific year?
No. Unix cron has no year field. The converter drops the constraint, flags the conversion as lossy, and the usual workaround is a date guard inside the job itself.