cron, explained

Paste a cron line, pick a time zone, see what it means and when it runs next (daylight-saving aware).

At 02:30.

  1. 2026-11-09T02:30:00-05:00
  2. 2026-11-10T02:30:00-05:00
  3. 2026-11-11T02:30:00-05:00
  4. 2026-11-12T02:30:00-05:00
  5. 2026-11-13T02:30:00-05:00
  6. 2026-11-14T02:30:00-05:00
  7. 2026-11-15T02:30:00-05:00
  8. 2026-11-16T02:30:00-05:00
  9. 2026-11-17T02:30:00-05:00
  10. 2026-11-18T02:30:00-05:00

Add the next runs to a calendar (.ics)

On daylight-saving nights

The list above follows systemd timer rules. cron daemons and Kubernetes don't always agree with it (measured here). Times within 3 hours of each change where they differ:

2027-03-14: clocks go forward, 02:00 → 03:00

Whensystemd timercronieKubernetes CronJob
03:00 (UTC-04:00)—runs—

2027-11-07: clocks go back, 02:00 → 01:00

Same in all three.

From a terminal

curl 'https://cron.wickkit.cc/?e=*/15+9-17+*+*+1-5&tz=Europe/Berlin&n=5'
curl 'https://cron.wickkit.cc/api?e=@weekly&tz=America/New_York'   # JSON
curl 'https://cron.wickkit.cc/ics?e=0+3+*+*+*&tz=Europe/Berlin&name=Backups'   # calendar

The calendar has the next 50 runs (n, up to 100), each d minutes long (default 15), titled name. Subscribe to the /ics URL ("From URL" in Google Calendar, "New Calendar Subscription" in Apple Calendar) and it keeps rolling forward.

Five fields (minute hour day-of-month month day-of-week), names like mon and jan, and the @daily-style macros. When both day fields are set, a day matches if either matches, as in standard cron. A time skipped by a daylight-saving jump doesn't run; a time that happens twice runs once (systemd's rule). Add &sched=cronie or &sched=k8s to /api for those rules, and /dst gives the daylight-saving comparison as JSON. cronie runs a job whose time was skipped right after the jump, unless its minute or hour field starts with *; Kubernetes runs a time that happens twice twice.

wickkit.cc