Cron Expression Visualizer

The Cron Expression Visualizer takes a cron expression and explains it in plain language. It shows how each field (minute, hour, day, month, weekday) contributes to the final schedule and generates a list of upcoming run times so you can verify behavior before deploying.

• Paste or type a cron expression into the Expression field.
• Optionally choose a timezone (e.g. UTC, local, or a specific IANA zone like Europe/Berlin).
• See a natural-language explanation like "Every day at 03:00" or "Every 5 minutes on weekdays".
• Review the preview table of the next N run times to confirm the schedule behaves as expected.

Many jobs follow a few common patterns. The visualizer can offer templates such as:

• Every minute
• Every 5 / 15 / 30 minutes
• Every hour / Every 6 hours
• Every day at HH:MM
• Every Monday at HH:MM

Selecting a template fills in a known-good expression. You can then tweak individual fields and immediately see how the schedule changes.

When you're migrating between systems or reviewing existing jobs, it's often useful to compare two expressions side by side:

• Paste the old cron expression and note the natural-language description and run-times.
• Adjust the new expression until both previews match.
• This is especially helpful when moving between cron implementations with slightly different semantics.

The most common cron format has five fields, usually interpreted as:

• minute – 0–59
• hour – 0–23
• day of month – 1–31
• month – 1–12 or names (JAN–DEC)
• day of week – 0–6 (often 0 = Sunday) or names (MON–SUN)

The visualizer breaks down each field and shows how wildcards (*), lists (1,2,3), ranges (1-5), and steps (*/5) contribute to the final schedule.

A few constructs show up frequently across cron fields:

• * – "every value" (e.g. every minute, every hour).
• 1-5 – range of values (e.g. Monday to Friday, hours 1–5).
• */5 – "every 5 units" starting at 0 (minutes 0,5,10,...).
• 1,15,30 – explicit list of values (e.g. run at 1, 15 and 30 minutes past the hour).

The tool expands these into human-readable descriptions so you don't need to mentally simulate them.

A classic source of confusion: how cron treats day of month and day of week when both are specified. Many implementations interpret this as:

• Run when either day-of-month or day-of-week matches.
• Some platforms add syntax like ? to mean "no specific value" in one field.

The visualizer follows the semantics of the specific cron flavor it's targeting (e.g. "standard" vs. "Quartz"). Always double-check documentation for your scheduler.

Cron expressions themselves are timezone-agnostic — the scheduler interprets them in some configured timezone. This becomes tricky around DST changes:

• Jobs around the "missing hour" may be skipped.
• Jobs around the "repeated hour" may run twice.
• Different platforms handle these edge cases differently (skip, run once, or run twice).

The visualizer can help by showing run-times in a specific timezone so you can see how DST transitions might affect your schedule.

Some cron implementations extend the basic syntax with extra fields, macros, or operators, for example:

• 6th field for year.
• Preset macros like @hourly, @daily, @weekly.
• Non-standard operators like L, W.

The visualizer focuses on the most common subset first, with room to add more cron "flavors" as needed. If a feature isn't supported, you'll get a clear indication instead of silently wrong output.

Internally, the visualizer parses the cron string into structured fields and then uses those to generate a sequence of upcoming run times:

• Split the expression into its individual fields.
• Parse ranges, lists, and step values for each field into numeric sets.
• Starting from a given "now", increment time until the next N timestamps that satisfy all field constraints are found.

All computation happens in your browser. No expressions or schedules are sent to Birdor's servers.

Cron expressions can theoretically describe very frequent schedules (e.g. every minute). The visualizer:

• Limits the number of preview run-times to a small, fixed count (e.g. next 20 runs).
• Caps iteration so pathological expressions don't lock up the UI.
• Validates field ranges and gives explicit errors for invalid or out-of-bound values.

• JSON Formatter & Viewer — useful when schedules are stored as JSON in your configs.
• URL Parser & Query Editor — handy if you pass cron expressions through query parameters or APIs.

In many production systems, cron expressions live in config files, JSON, or environment variables. Keeping the Cron Visualizer open next to your editor makes it much easier to verify changes before they hit real job runners.