Cron Expression Builder: Quartz, AWS, DST aware

What does the builder do?

The cron expression builder is a live editor for the four dominant cron dialects: classic Unix cron with five fields, Quartz with six or seven fields, AWS EventBridge with a fixed six-field form, and Spring @Scheduled with the same six-field form without year. As you type, the builder converts the expression into a plain-English sentence, lists the next five executions in your IANA timezone, and flags daylight-saving transitions, impossible date combinations and the OR-trap when day-of-month and day-of-week are both set.

Below the explanation you get how often the schedule really fires: per run day, per month and per year. * * * * * is 525,600 runs a year, 527,040 in a leap year. Anyone paying per invocation should have seen that number before the deploy. Where the calendar refuses to give a fixed figure, you get a span and the reason for it instead of an invented number, because a year holds 52 or 53 Mondays, and with day-of-month and day-of-week both set the OR-logic counts both hits. Clicking a field shows what it means, the value range in the picked flavor and the special characters allowed there. Expression, flavor and timezone also sit in the address, so a shared link opens the same state.

Pure-client. Every expression stays in your browser. No server, no tracking, no cookie wall. The tool works offline once the page is loaded.

Why do you need a builder for cron at all?

Cron looks harmless. Five stars are enough to hit every minute. But the moment you get specific the edges bite. 0 0 31 2 * parses cleanly as every February 31 at midnight, yet never runs. 0 0 * * 0,1 seems to run only Sunday and Monday, that holds on systemd timers, but classic Vixie-cron implementations combine the two day fields with OR, so you hit twice as many days as expected. 0 2 * * * runs 364 days a year, and the one Sunday in March when DST starts, it does not run, because 02:00 simply does not exist in many European timezones. AWS EventBridge documents this behind a paragraph that opens with the phrase intentionally skipped.

The builder catches all three classes in one surface: the plain-English explanation, the next-run list in your timezone, and the notes panel naming DST, OR-trap and impossible dates in a uniform voice.

Four dialects in one editor

Unix cron is the five-field form that ships with every Linux distribution. Quartz, the scheduler powering Spring Batch and Quartz.NET, prepends a seconds field and optionally appends a year field. Quartz counts day-of-week from 1 to 7 with Sunday as 1, Unix from 0 to 7 where both 0 and 7 mean Sunday. AWS EventBridge takes the Quartz shape including that numbering. Both require exactly one question mark, in day-of-month or day-of-week, and the builder rejects anything else. Spring @Scheduled is a Quartz clone minus year, but it counts day-of-week the Unix way.

The builder picks between the four dialects via the segmented tab at the top. Every preset click (Hourly, Weekdays 09:00, Weekend 10:00) automatically pulls the matching expression for the current flavor. Switching flavors translates a preset hit along with it, so you do not retype.

Plain-English explanation: voice-search-first

The first line of the explanation answers the question directly, example: Every Monday at 09:00. The convention helps voice-search and LLM-citation: the sentence works as a snippet without further context. Google Assistant and Perplexity answers typically read the first ten words of the first paragraph aloud, the explanation is shaped to fit that envelope.

Timezone preview

The next-run list runs underneath via Intl.DateTimeFormat and checks each calendar day in the target zone for month, day and weekday before resolving that day’s clock times in the target IANA slot. Eight popular timezones are preset: UTC, Europe/Berlin, Europe/London, America/New_York and four others. The IANA timezone database is the world reference for timezone data, browsers, servers and runtime libraries all rely on it.

DST warning

The builder looks up the next clock changes in the chosen zone, about thirteen months ahead, and checks for each one whether a scheduled time falls into the hour that disappears or the hour that repeats. Only then does a note appear next to the next-run list, carrying that zone’s real jump: On 2027-03-28 the 02:30 run does not happen, the clock jumps from 02:00 to 03:00 or On 2026-10-25 the 02:30 run fires twice, the clock goes back from 03:00 to 02:00. The jump is measured, not assumed: Pacific/Chatham moves its clock at 02:45 and Australia/Lord_Howe moves it by half an hour, and that is what the note then says. The sentences defuse the most common misassumption in backup and reporting jobs.

What does the semantic validation catch?

Syntactically valid does not mean semantically sensible. The builder distinguishes three classes:

• Never runs, 0 0 31 2 * parses cleanly, but 31 February does not exist. The builder catches this against the table of month lengths and flags the warning immediately.
• OR-trap, When day-of-month and day-of-week are both set, Vixie-cron joins with OR and systemd/Spring with AND. 0 0 1 * MON runs on Vixie-cron every first of the month plus every Monday, on systemd only the first that is also a Monday. The warning names both implementation expectations so the reviewer does not get surprised later.
• Flavor mismatch. Typing seconds in a Unix cron or putting ? in a Unix field returns a clear flavor-mismatch note instead of a silent parse failure.

Which exports are wired up?

Four target formats are wired up. Each emits the exact block you can paste into your YAML, manifest or crontab:

Every export is translated into the target’s dialect, not merely passed through. An AWS expression with a question mark and a year field is rewritten into five valid Unix fields for the crontab, and a Unix expression becomes six fields with a question mark for EventBridge. Anything the target cannot run ships commented out with the reason above it, so a blind paste cannot install a broken schedule.

• crontab: a plain cron line plus comment header and CRON_TZ for the chosen zone, so the job does not run in whatever zone the server is set to. Drops into crontab -e or an /etc/cron.d file.
• GitHub Actions: full on.schedule block with name and single-quoted cron. The time is left in your own zone, next to the timezone: key GitHub Actions has understood since March 2026. Below it, commented out, the same line converted to UTC for older GitHub Enterprise Server releases without that key; there, a conversion that shifts the day shifts the weekday with it.
• Kubernetes CronJob: full manifest with apiVersion: batch/v1, kind: CronJob, spec.timeZone for the chosen zone, a DNS-1123 sanitised name and a busybox sample container. You only swap image and command.
• AWS EventBridge: cron(...) wrap in the six-field form with year and question mark that the AWS console requires.

What is intentionally out of scope?

The builder is builder-only: it plans, validates and exports. Monitoring, alerting, history and cron-job invocation belong elsewhere. These features are intentionally out of scope:

• No monitoring or dead-man’s-switch, Cronitor and similar services own that lane.
• No history beyond the current session, the no-localStorage hard-cap applies here too.
• No simulation beyond four years, 0 0 29 2 * would freeze the preview otherwise.
• No vendor dialects (Jenkins H-hash, Nomad-specific, Camel-Quartz extensions).
• No NLP text-to-cron translation, that belongs in LLM tools and breaks the pure-client promise.

How is privacy handled?

The builder runs entirely in your browser. There is no server call, no telemetry endpoint, no cookie banner. The only host APIs used are new Date() for the next-run anchor and Intl.DateTimeFormat for IANA timezone math. Both are web standards with no tracking implication.

Which references are related?

• Cron on Wikipedia: history, Vixie-cron, systemd timers
• IANA timezone database: source for DST transition dates
• GitHub Actions cron docs the canonical reference for the on.schedule block (UTC semantics)