CronLens

GitHub Actions cron schedule checker

The schedule event in a workflow uses five-field POSIX-style cron, UTC by default. Enter an expression to see what it means and when it will run, then copy a ready workflow trigger. The check runs entirely in your browser.

    Workflow file

    History and favourites (stored only in this browser)

      Nothing saved yet. Expressions you check are saved here, in your browser's local storage, never on a server.

      Runs locally. The expression is never uploaded. The share link keeps it after the # sign, which browsers never send to a server.

      How to use

      1. Type the five fields: minute, hour, day of month, month and day of week. Months may be written JAN to DEC and days SUN to SAT, or as numbers (0-6 for days, Sunday being 0).
      2. Leave the time zone as UTC to model the default, or type an IANA name to model the optional timezone key. The snippet adds the key only when the zone is not UTC.
      3. Read the next runs and the warnings. A warning appears for intervals under the documented five-minute minimum and for the start of the hour, where GitHub reports delays.
      4. Copy the workflow snippet. It includes workflow_dispatch so that you can start the job by hand and confirm that it works without waiting for the schedule.
      5. Commit the workflow to the default branch. Scheduled workflows are read from there.

      Worked examples

      Weekday mornings at 04:17 UTC

      17 4 * * 1-5 runs Monday to Friday. Starting after 05:00 UTC on Thursday 1 October 2026, the next run is Friday, and the weekend is skipped.

      GitHub Actions, time zone UTC, runs after 2026-10-01 05:00 UTC
      17 4 * * 1-5

      1. Fri 2026-10-02 04:17:00 +00:00
      2. Mon 2026-10-05 04:17:00 +00:00
      3. Tue 2026-10-06 04:17:00 +00:00

      The documentation's stepped example

      20/15 * * * * starts at minute 20 and repeats every 15 minutes, so the minutes are 20, 35 and 50 of every hour. Notice that there is no run at minute 5: a step with a start value runs forward from the start to the end of the range and does not wrap around.

      GitHub Actions, time zone UTC, runs after 2026-10-01 00:00 UTC
      20/15 * * * *

      1. Thu 2026-10-01 00:20:00 +00:00
      2. Thu 2026-10-01 00:35:00 +00:00
      3. Thu 2026-10-01 00:50:00 +00:00
      4. Thu 2026-10-01 01:20:00 +00:00

      A schedule in another time zone

      The GitHub documentation shows 30 5 * * 1-5 with timezone: "America/New_York". On 1 October 2026 New York is on daylight time, so the offset is -04:00.

      GitHub Actions, time zone America/New_York, runs after 2026-10-01 00:00 UTC
      30 5 * * 1-5

      1. Thu 2026-10-01 05:30:00 -04:00
      2. Fri 2026-10-02 05:30:00 -04:00
      3. Mon 2026-10-05 05:30:00 -04:00

      Spring forward: 02:30 does not exist in New York on 8 March 2026

      GitHub documents that a time skipped by the clock change advances to the next valid time: a 2:30 AM schedule runs at 3:00 AM that day. On other days it runs at 02:30 as usual.

      GitHub Actions, time zone America/New_York, runs after 2026-03-07 12:00 UTC
      30 2 * * *

      1. Sun 2026-03-08 03:00:00 -04:00
      2. Mon 2026-03-09 02:30:00 -04:00
      3. Tue 2026-03-10 02:30:00 -04:00

      Limits & gotchas

      • Fall-back is not documented. GitHub describes the spring-forward case but not what happens when a time occurs twice. This tool shows a single run at the first occurrence and labels that as unclear.
      • Delays and dropped runs. The documentation says high load, including the start of every hour, can delay a scheduled run and in rare cases drop it. Treat the listed times as the earliest start.
      • Five-minute minimum. Shorter intervals are not supported.
      • Default branch only. A schedule on a feature branch does nothing until the workflow reaches the default branch.
      • 60 days of inactivity. In public repositories scheduled workflows are switched off after 60 days without activity, and are disabled by default in forks.
      • Syntax. Only *, ,, - and / are supported. GitHub calls it POSIX cron syntax and says nothing more about how the day-of-month and day-of-week fields combine. This tool follows classic cron and treats a restriction on both as "either matches", which is the POSIX rule, and warns when you do it. Check the result with workflow_dispatch if it matters.

      FAQ

      What time zone does a GitHub Actions schedule use?

      According to the current GitHub documentation, scheduled workflows run in UTC by default, and you can add an optional timezone key (an IANA name such as America/New_York) next to cron to evaluate the schedule in another zone. Older articles say "UTC only", which is out of date.

      Why did my scheduled workflow start late or not at all?

      GitHub states that scheduled runs can be delayed during periods of high load, including the start of every hour, and that if the load is high enough some queued jobs may be dropped. Choose a minute that is not :00, for example 17 instead of 0, to avoid the busiest moment.

      Why did my schedule stop running?

      Two documented reasons. Scheduled workflows only run for the workflow file on the default branch. And in a public repository, scheduled workflows are automatically disabled when there has been no repository activity for 60 days; you can re-enable them from the Actions tab. Scheduled workflows are also disabled by default in forks.

      What is the shortest interval I can schedule?

      GitHub documents five minutes as the shortest interval. The tool shows what the expression says and warns when it can fire more often than every five minutes; we have not tested what GitHub does with such an expression, so do not rely on it.

      Can I use @daily or @hourly in a workflow?

      No. GitHub lists @yearly, @monthly, @weekly, @daily, @hourly and @reboot as unsupported. Write the five fields. Only the operators *, comma, hyphen and slash are supported.

      Sources

      Every document above was opened and read on 2026-10-01. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.