Crontab generator with multi-flavor compile and gotcha warnings

A crontab generator answers two questions at once: what your cron line means in plain language, and whether the platforms you ship it to will accept it. Toolflux runs five flavors in parallel: Vixie/Linux, Quartz, AWS EventBridge, GitHub Actions, and Kubernetes. The compatibility matrix marks each target as legal-equivalent, legal-but-different, or rejected, with a copy-pasteable snippet per row.

What does 0 0 15 * 5 mean in cron?

0 0 15 * 5 fires on the 15th of every month AND on every Friday under Vixie/Linux - not just on Fridays that happen to fall on the 15th. POSIX cron joins day-of-month (DOM) and day-of-week (DOW) with OR whenever both fields are set. "The 15th, if it's a Friday" becomes "roughly 62-63 times a year" (52 Fridays plus 12 fifteenths minus the one or two overlap days).

The trap is well-known because POSIX cron deliberately deviates from the gut-feel reading. If you genuinely want only Friday-the-15th, you need a shell guard inside the job script, not a cron expression. The diagnostics strip surfaces the warning automatically as soon as DOM and DOW are both restrictive and you're in the Vixie, GitHub Actions, or Kubernetes flavor.

Quartz and AWS EventBridge behave differently: they require one of the two fields to be ?, so they have no OR rule to fall into. That difference is the root cause of many "my schedule fires differently on AWS" threads.

Why doesn't my GitHub Actions cron run?

Three frequently documented causes sit behind the silent misses on GitHub Actions. Each one gets its own line in the diagnostics strip as soon as you switch the flavor to GitHub Actions. It's rarely just "my cron is broken" - it's usually one of these three.

• Leading zero in numeric fields (08 instead of 8). Vixie cron and most online validators take it; community reports note that the workflow in GitHub Actions can be quietly disabled without surfacing an error - the official docs are silent on it. Write 8, never 08.
• Top of the hour under load. Workflows scheduled at minute 0 get delayed or skipped when the platform is busy. Picking any minute other than 0 reduces the risk - GitHub itself recommends this in the on.schedule docs.
• Default-branch only. Cron triggers only fire when the workflow file lives in the default branch (typically main). On a feature branch, the cron block is decorative.

Timezone is the quiet fourth: GitHub Actions schedules on.schedule triggers in UTC by default. The timezone selector here projects the next runs into your local time so you can see the offset; GitHub's engine itself stays on UTC for on.schedule unless you explicitly override it.

How is AWS EventBridge cron different from Linux cron?

AWS EventBridge looks like cron, but it differs in four places that are big enough to make a verbatim Linux paste misfire reliably. The compatibility matrix translates automatically and flags the rows where firing behaviour changes. Read it as an explanation, not a rejection - the corrected snippet sits right next to the note.

A common import bug is the DOW offset: the same numeric value 5 means Friday on Linux and Thursday on AWS. Port a Linux crontab line over and copy the value blindly, and your job fires a day early - until you notice the confirmation email arriving on the wrong weekday.

What does */5 expand to in cron?

*/5 in the minutes field doesn't mean "any minute that's divisible by 5". It means "start at the field's lower bound and iterate in 5-step intervals". For minutes the lower bound is 0, so the result happens to coincide with the modulo reading. For other fields it doesn't.

Three examples that pull the meanings apart:

1. Minutes: */5 yields 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55. Modulo and step-from-zero give the same set - the two readings overlap here.
2. Hours with offset: 5/5 in the hour field yields 5, 10, 15, 20. Not 0, 5, 10, 15, 20 - the iteration starts at 5, not at 0.
3. Days of month: */5 in the DOM field yields 1, 6, 11, 16, 21, 26, 31. The lower bound is 1, not 0, and the 31st doesn't exist in every month - February costs you one iteration.

If you want steps with an explicit offset, write start/step directly (5/15 instead of */15 plus mental correction). The diagnostics strip won't flag step logic on its own, but the next-runs list makes the offset visible: when the minutes aren't where you expected, this is usually why.

Frequently Asked Questions

Which cron flavors does the tool cover?

Five: Vixie/Linux (5 fields, the POSIX classic), Quartz (6 or 7 fields with seconds and an optional year - the Java Quartz Scheduler format, not Spring @Scheduled, which uses its own non-compatible cron dialect), AWS EventBridge (6 fields, ? required, UTC by default), GitHub Actions (5 fields, UTC by default, with several quirks around triggers and drop behaviour), and Kubernetes CronJob (5 fields, POSIX). Pick the source flavor up top and the compatibility matrix re-renders into the other four automatically. Coverage is the common syntax (numbers, ranges, steps, lists, names, *, ?); the Quartz extensions L, W, # and years past 2099 aren't supported yet.

What does the ? in AWS or Quartz expressions mean?

? means "not specified" and is only legal in the day-of-month or day-of-week field. Both flavors disallow restricting both fields at once - you give either a DOM value plus ? for DOW, or the reverse. Vixie/Linux has no ? at all; there both fields can carry values, and the DOM-OR-DOW rule applies.

Why does my expression change when I switch flavors?

Switching the flavor selector re-compiles the current expression into the target flavor's syntax. If the translation is lossless (e.g. Vixie to Kubernetes), the semantics stay identical. If it isn't (e.g. Quartz with seconds going to Vixie which has no seconds), the input falls back to the target flavor's canonical default so you never land on an "expression invalid" error page.

Which timezone does the next-runs list use?

Default is the browser timezone. You can set any IANA zone in the timezone field (e.g. Europe/Berlin, America/New_York, Asia/Tokyo) and the list re-projects accordingly. The underlying schedule logic is unaffected; only the display shifts. AWS EventBridge and GitHub Actions both schedule in UTC by default on their own engines; the timezone picker here is a display aid, not an override for those platforms.