Run Calendar

See exactly when your cron fires on a month grid — and catch the daylight-saving surprises that silently break real schedules.

Try It Now

Open the validator, type an expression, then switch the Upcoming runs panel from List to Calendar. No account needed.

Open Validator →

What the calendar shows

Each day of the month is a cell. Days when your job runs are filled in; quiet days are left blank. How a day renders depends on how often it fires:

302:3014:30A few runseach time is listed8◆03:30DST transition daybadged with a ◆1596× runsA busy dayshows a run count

Hover any day to see the full list of fire times. The footer under the grid reports the total runs for the month and the timezone the times are shown in.

How to use it

  1. 1

    Enter your expression

    Type a cron expression (or pick a preset) in the validator.

  2. 2

    Pick a timezone

    The calendar evaluates and displays runs in the timezone you select — DST behaviour depends on it.

  3. 3

    Switch to Calendar

    Toggle the Upcoming runs panel from "List" to "Calendar".

  4. 4

    Travel through time

    Use the ‹ and › arrows to move between months, or "Today" to jump back. Look ahead to month-boundary and DST edge cases before they happen.

Spotting daylight-saving problems

The single most common cron outage is a daily job set for a wall-clock time that, on the day the clocks change, either doesn't exist or happens twice. The calendar marks those days with a ◆ so you can see them at a glance.

1:001:592:00–2:59 never happensclocks jump forward✗ 2:30 job skipped3:004:00Spring forward: a 2:30 daily job never fires that day
⚠️

Spring forward — a skipped run

Try 30 2 * * * in America/New_York and travel to March. The transition day is badged, and you'll see the run shifted to 03:30 — some platforms skip it entirely instead. Either way, it did not run at 2:30.

⚠️

Fall back — a doubled run

Try 30 1 * * * in America/New_York and travel to November. The 01:30 hour happens twice, so the job can fire twice. The day is badged so you can plan for idempotency.

Timezones without DST (for example UTC or Asia/Tokyo) never show these badges — switching the timezone selector is a quick way to confirm a schedule is DST-safe.

High-frequency schedules

Expressions like */15 * * * * or * * * * * fire too often to list. Those days show a compact N× runs count instead. The monthly total in the footer reflects reality — on a spring-forward month it's a little lower, because the skipped hour removes those slots.

For extremely frequent schedules the grid caps how many runs it computes and shows a notice; the validator's frequency warning tells you the full per-year figure.

What it's good for

Confirming month-boundary behaviour

See instantly that 0 0 31 * * skips February, April, June, September, and November.

Verifying business-hours coverage

Check a weekday schedule lands on the right days, including around month edges.

Auditing DST safety before deploy

Travel to March and November and confirm no critical job sits in a skipped or doubled hour.

Sanity-checking frequency

A wall of N× runs pills is a fast visual cue that a schedule fires more than you intended.