Cron Syntax Across Platforms: Why the “Same” Expression Behaves Differently

Cron looks universal, but the dialect changes from one system to the next. A line that works perfectly in a Linux crontab can fail to load in Quartz, run an hour off in GitHub Actions, or be rejected outright by a cloud scheduler. This comparison lays out the differences that actually bite – field count, time zone, and special characters – so you can move a schedule between platforms without surprises. Validate any five‑field expression first with the cron generator, then adapt it using the notes below.

Classic Unix crontab (the baseline)

The original is the five‑field format documented by Vixie cron, which ships with most Linux and BSD systems: minute, hour, day‑of‑month, month, day‑of‑week. It runs in the server’s local time zone, supports *, ranges, lists and */n steps, and accepts three‑letter month and day names. It also adds the @daily, @hourly, @weekly, @monthly and @reboot macros. This is the dialect our tool speaks, and it is the lowest common denominator: if your expression is valid plain five‑field cron, it is the most portable thing you can write.

Quartz (Java / Spring)

Quartz, common in Java and Spring applications, looks similar but is not the same language. It uses six or seven fields, not five: it prepends a seconds field and appends an optional year field. So a Quartz expression for “every day at 10:15am” is 0 15 10 * * ? – note the seconds 0 at the front. Quartz also forbids using * in both the day‑of‑month and day‑of‑week fields at once; one of them must be a ? meaning “no specific value.” On top of that it adds powerful tokens: L for the last day of the month or week, W for the nearest weekday to a date, and # for the nth weekday (so 6#3 is the third Friday). None of these are portable back to Unix cron, so a Quartz line pasted into a crontab will simply error.

Kubernetes CronJobs

Kubernetes CronJobs use the familiar five‑field syntax, which makes them easy to read, but with a few operational twists. The schedule has historically been interpreted in UTC, though newer versions let you set a timeZone field explicitly – worth checking on your cluster version. Kubernetes also adds concurrency controls and a startingDeadlineSeconds setting that governs what happens if the controller was down when a job should have fired. The expression itself is standard, but whether a missed run is caught up or skipped depends on these surrounding fields, not on the cron text.

GitHub Actions

GitHub Actions accepts five‑field POSIX cron in the schedule: trigger, with two big caveats. First, it always runs in UTC – there is no time‑zone option, so a “9am” job has to be written as the UTC equivalent for your region, and it will not follow daylight‑saving shifts. Second, scheduled runs are best‑effort: during periods of high load GitHub may delay or drop them, and the shortest reliable interval is around five minutes. If you need exact timing, GitHub Actions cron is the wrong tool; for routine maintenance it is fine. Because the field syntax is identical to Unix, you can prototype in our generator and just remember to convert your local time to UTC.

Cloud schedulers (AWS, Google Cloud, Azure)

The big clouds each have their own scheduling service, and they diverge further. Amazon EventBridge Scheduler and the older CloudWatch Events use a six‑field cron expression with a required year field, and they too use ? to mean “no specific value” in the day fields – closer to Quartz than to Unix. They also require the expression to be wrapped as cron(...) and historically ran in UTC, though EventBridge now supports time zones and even flexible time windows. Google Cloud Scheduler, by contrast, sticks to the classic five‑field Unix format and lets you attach an IANA time‑zone name such as America/New_York, so it handles daylight saving correctly. Azure Logic Apps and Functions use yet another variant (an NCronTab six‑field format with seconds). The lesson: never assume the field count.

A migration checklist

When you move a schedule between platforms, run through four questions. How many fields? Five for Unix, Kubernetes, GitHub and Google; six or seven for Quartz and AWS; six with seconds for Azure. Which time zone? Local for classic cron, UTC for GitHub and older cloud services, configurable for Google Cloud Scheduler and newer EventBridge. Day‑field rule? Unix uses the OR behaviour and bare *; Quartz and AWS require a ? in one day field. Special tokens? L, W and # exist only in Quartz‑style dialects, so rewrite them if you are heading to plain cron.

Because the five‑field Unix form is the common ancestor of all these dialects, it is the safest place to design a schedule. Get the minute, hour and day pattern right in the generator, confirm the next‑run preview matches your intent, and only then translate it – adding a seconds field, a year, a ? or a time‑zone setting – for the platform you are deploying to. For the underlying syntax rules themselves, the cron syntax guide covers every operator in detail.