Cron expression builder and explainer
Type a cron expression, choose which system will run it, and see what it means in plain English and when it will fire next, with the time zone and daylight saving changes taken into account. Everything is calculated in your browser.
| # | Local time | Offset | UTC | In |
|---|
How this dialect handles daylight saving time
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
- Choose the dialect. This is the system that will actually read the expression: Linux cron, a Kubernetes CronJob, a GitHub Actions workflow, a Quartz scheduler or AWS EventBridge. The field layout changes with this choice, and the line under the box shows the field order the tool expects.
- Type or paste the expression, or pick a starting point from Start from an example and edit it. Errors are reported next to the box and say which field is wrong and why. Warnings appear for things that are accepted but surprising.
- Set the time zone that the schedule is evaluated in and how many upcoming runs you want. Each row shows the weekday, the local date and time, the UTC offset and how far away it is.
- Read the daylight saving note below the list. It tells you whether that dialect skips, shifts or repeats a run when clocks change, and how well that behaviour is documented.
- Use Copy link to share the exact expression, dialect and zone. Use Save to keep it in this browser's history. Both stay on your device unless you paste the link somewhere yourself.
For the dialects that have extra settings, the dedicated pages add a ready-to-paste snippet: the Kubernetes CronJob page produces a manifest, the GitHub Actions page a workflow trigger and the AWS page a command line.
Worked examples
Every list below was worked out by hand from the calendar and the documented rules before being compared with the tool, and the page prints exactly the values the automated tests check. The reference date is Thursday 1 October 2026.
Linux: every 15 minutes during office hours
*/15 9-17 * * mon-fri means minutes 0, 15, 30 and 45 of hours 9 to 17, on Monday to Friday. The last run of a day is 17:45, because hour 17 lasts until 17:59.
Linux / Vixie cron, time zone UTC, runs after 2026-10-01 16:50 UTC*/15 9-17 * * mon-fri
Thu 2026-10-01 17:00:00 +00:00Thu 2026-10-01 17:15:00 +00:00Thu 2026-10-01 17:30:00 +00:00Thu 2026-10-01 17:45:00 +00:00Fri 2026-10-02 09:00:00 +00:00Fri 2026-10-02 09:15:00 +00:00
Linux: both day fields set means "either"
30 4 1,15 * 5 is the example from the crontab(5) manual page. It fires on the 1st, the 15th and every Friday.
Linux / Vixie cron, time zone UTC, runs after 2026-10-01 00:00 UTC30 4 1,15 * 5
Thu 2026-10-01 04:30:00 +00:00Fri 2026-10-02 04:30:00 +00:00Fri 2026-10-09 04:30:00 +00:00Thu 2026-10-15 04:30:00 +00:00Fri 2026-10-16 04:30:00 +00:00Fri 2026-10-23 04:30:00 +00:00
Linux: a step restarts in every period
*/35 * * * * does not mean "every 35 minutes". It means minutes 0 and 35 of every hour, so the gaps are 35 minutes and then 25 minutes.
Linux / Vixie cron, time zone UTC, runs after 2026-10-01 00:00 UTC*/35 * * * *
Thu 2026-10-01 00:35:00 +00:00Thu 2026-10-01 01:00:00 +00:00Thu 2026-10-01 01:35:00 +00:00Thu 2026-10-01 02:00:00 +00:00
Linux: a star-with-a-step day field switches "either" into "both"
In cronie, a day field that starts with * (even */2) is treated as unrestricted, so the day-of-month and day-of-week tests are combined with AND. Kubernetes uses a different library, which treats a stepped star as restricted. The same text gives different answers:
Linux / Vixie cron, time zone UTC, runs after 2026-10-01 00:00 UTC0 0 */2 * 1
Mon 2026-10-05 00:00:00 +00:00Mon 2026-10-19 00:00:00 +00:00Mon 2026-11-09 00:00:00 +00:00
Kubernetes CronJob, time zone UTC, runs after 2026-10-01 00:00 UTC0 0 */2 * 1
Sat 2026-10-03 00:00:00 +00:00Mon 2026-10-05 00:00:00 +00:00Wed 2026-10-07 00:00:00 +00:00Fri 2026-10-09 00:00:00 +00:00Sun 2026-10-11 00:00:00 +00:00Mon 2026-10-12 00:00:00 +00:00
The first list has only Mondays that fall on an odd day. The second list has every odd day and every Monday. This difference comes from reading the two implementations' source code, and we confirmed the Kubernetes side by running the Go library; the manual pages do not spell it out.
Limits & gotchas
The dialects compared
| Dialect | Fields | Sunday is | Time zone | Notable rules |
|---|---|---|---|---|
| Linux (cronie) | 5: minute hour day-of-month month day-of-week | 0 or 7 | Daemon's zone; CRON_TZ in the crontab | Names, macros including @reboot; both day fields restricted means OR |
| Kubernetes | 5, same order | 0 (range 0-6) | .spec.timeZone; CRON_TZ or TZ inside the schedule is rejected | ? is the same as *; macros except @reboot |
| GitHub Actions | 5, same order | 0 (range 0-6) | UTC unless the timezone key is set | Only * , - /; no macros; 5-minute minimum |
| Quartz | 6 or 7: second first, optional year last | 1 (SUN) | The trigger's time zone | One day field must be ?; L W # |
| AWS EventBridge | 6: minute hour day-of-month month day-of-week year | 1 (SUN) | Scheduled rules: UTC only. Scheduler: your choice | One day field must be ?; year is required |
What this tool cannot tell you
- It is a model, not the scheduler. The Kubernetes and Quartz engines were compared against the real libraries (Quartz 2.3.2 and robfig/cron v3.0.1, the library Kubernetes uses) on randomly generated expressions (see the About page), but Linux cron, GitHub and AWS were compared with their documentation only.
- Start-up delay is not modelled. GitHub says scheduled runs can be delayed under load, Kubernetes checks for due jobs about every ten seconds and AWS says a rule can lag by several seconds. The times here are the scheduled instants, not the moments work begins.
- Daylight saving behaviour is partly undocumented. The note under each list says whether it is documented, observed or unclear. Treat "observed" as a snapshot of one library version.
- Some dialects share a name but not a grammar. If your platform is not in the list (for example a managed workflow service or a different Java library) it may accept or reject expressions this tool does the opposite with.
FAQ
Is the cron expression I type sent to a server?
No. The parsing, the explanation and the run times are calculated by JavaScript in your browser tab. Nothing you type is uploaded. The address bar can hold your expression after a # sign so you can share it, and browsers never send that part of a link to a server.
Why does the same expression behave differently in Linux, Kubernetes, GitHub Actions, Quartz and AWS?
Because they are different dialects that share a family resemblance. Quartz and AWS EventBridge require a ? in one of the two day fields, Quartz adds a seconds field at the front, AWS adds a year at the end, Linux cron counts Sunday as 0 or 7 while Quartz and AWS count Sunday as 1, and only some of them accept names, macros or special characters such as L, W and #. Pick the dialect first, then read the explanation.
What does "30 4 1,15 * 5" mean on Linux?
It runs at 04:30 on the 1st and the 15th of every month and also at 04:30 on every Friday. When both day-of-month and day-of-week are restricted, classic cron runs the job when either one matches. That is the example used in the crontab(5) manual page. In Quartz and AWS you are not allowed to restrict both fields, which is the reason the ? exists.
Which time zone are the run times shown in?
The one in the time zone box. It starts as your browser's time zone, or the zone saved from your last visit, and you can type any IANA name such as America/New_York. Each run shows its UTC offset so that a daylight saving change is visible.
Can I trust the next-run list when clocks change?
It follows what each product documents and says so under the list. Where a product documents the behaviour (AWS Scheduler, and GitHub for the spring-forward hour) the tool follows the documentation. Where the documentation is silent or contradicts itself (Kubernetes, Quartz, Linux cron) the page labels the behaviour as observed or unclear. If a job must run exactly once per day, do not schedule it inside the hour that clocks skip or repeat.
Sources
- Linux man-pages (cronie): crontab(5) Used for: Field list, day-of-month/day-of-week OR rule, steps, names, CRON_TZ, @-nicknames, the DST sentence about missing and repeated times, */N restarts each period.
- Linux man-pages (cronie): cron(8): Daylight Saving Time and other time changes Used for: Changes under three hours: fixed-time jobs run immediately after a skipped hour and are not repeated after a fallback; frequent jobs run normally.
- cronie (source code): src/cron.c and src/entry.c Used for: How cronie treats jobs whose minute or hour field starts with * ("wildcard" jobs) during clock changes, and how the day-of-month/day-of-week OR is implemented.
- The Open Group (POSIX.1-2017): crontab: schedule periodic background work Used for: The standard statement that when day-of-month and day-of-week are both restricted, either may match.
- Kubernetes: CronJob Used for: Schedule syntax, "?" = "*", macros, .spec.timeZone, CRON_TZ/TZ rejection, concurrencyPolicy, startingDeadlineSeconds, 100 missed schedules rule, 52-character name limit.
- robfig/cron (Go): cron v3 package documentation Used for: The library Kubernetes uses. Documents CRON_TZ and warns that jobs scheduled during daylight-saving leap-ahead transitions will not run.
- GitHub Docs: Events that trigger workflows: schedule Used for: UTC default, optional IANA timezone, 5-minute minimum, delays at the start of every hour, default-branch only, 60-day inactivity disable on public repositories, unsupported @-macros, DST spring-forward rule, five-field syntax and operators.
- Quartz Scheduler: CronTrigger Tutorial (2.3.0) Used for: Field table, special characters (? L W # and L-n, LW), examples, the rule that day-of-week and day-of-month cannot both be specified, DST caution.
- Amazon Web Services: Setting a schedule pattern for scheduled rules (legacy) in Amazon EventBridge Used for: Six required fields, field ranges, wildcards, the "?" rule, # limitation, minimum one-minute rate, UTC examples, year 1970-2199.
- Amazon Web Services: Schedule types in EventBridge Scheduler Used for: Time zones (IANA), 60-second precision, daylight saving rules (skip in the gap, once in the overlap), cron expression fields.
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.