illari

Cron expression tester

Paste a cron expression and a timezone. You get the next dozen run times in that timezone and in UTC, with daylight-saving changes marked. Everything runs in your browser.

Next 12 runs in UTC (GMT+0)

24 hr between the next two
  1. Mon, Aug 31, 03:00 AM2026-08-31 03:00 UTC
  2. Tue, Sep 1, 03:00 AM2026-09-01 03:00 UTC
  3. Wed, Sep 2, 03:00 AM2026-09-02 03:00 UTC
  4. Thu, Sep 3, 03:00 AM2026-09-03 03:00 UTC
  5. Fri, Sep 4, 03:00 AM2026-09-04 03:00 UTC
  6. Sat, Sep 5, 03:00 AM2026-09-05 03:00 UTC
  7. Sun, Sep 6, 03:00 AM2026-09-06 03:00 UTC
  8. Mon, Sep 7, 03:00 AM2026-09-07 03:00 UTC
  9. Tue, Sep 8, 03:00 AM2026-09-08 03:00 UTC
  10. Wed, Sep 9, 03:00 AM2026-09-09 03:00 UTC
  11. Thu, Sep 10, 03:00 AM2026-09-10 03:00 UTC
  12. Fri, Sep 11, 03:00 AM2026-09-11 03:00 UTC

How a cron expression reads

Five fields, separated by spaces: minute hour day-of-month month day-of-week. A * means “every.” So 0 3 * * * is 03:00 every day, */15 * * * * is every fifteen minutes, and 0 9 * * 1-5 is 09:00 Monday through Friday.

The timezone matters because 0 2 * * * in America/New_York is a different moment in January than in July, and on the two days a year the clocks move it's either ambiguous or doesn't exist at all. The tester resolves each run through the IANA timezone database so those days are handled rather than guessed.

Why daylight saving trips up job monitoring

A lot of monitoring tools check “has this job pinged in the last N minutes?” That works until a DST transition shifts the wall clock by an hour: a daily 2 a.m. job is suddenly 60 minutes early or late relative to the fixed window, and you get a false alert — twice a year, on a weekend.

illari computes each expected run from the cron expression and timezone the same way this tester does, so the window moves with the clock. More on catching silent cron failures →