How runs are calculated

Parsing

Each dialect has its own parser settings, taken from its official documentation: which fields exist, which characters they allow, how Sunday is numbered and how the two day fields combine. If a scheduler would reject an expression, you get the reason and, where possible, a fix.

Next runs

The run list comes from the expression, the zone and the start time. The zone rules come from your browser, through its built-in time zone data. Browsers ship different versions of that data, so a zone whose rules recently changed can differ from your server. For instance, tzdata 2026 and older data disagree about Morocco’s future offsets.

What each dialect’s behaviour is based on

Kubernetes

A port of the Next loop in robfig/cron v3.0.1. Its results are compared with the real library across about 2,800 expression, zone and date combinations, including transition days in 11 zones.

Quartz

A port of getTimeAfter from Quartz 2.5.2. Its results are compared with the real library across about 5,500 combinations. Quartz’s main branch has changed this code since, so other versions can differ at clock changes.

Azure

A port of CronSchedule from azure-webjobs-sdk-extensions, checked against the test tables in that project and in NCrontab. There was no .NET runtime to compare with directly.

EventBridge

The rules in AWS’s documentation, with Quartz’s reading for cases AWS leaves open. AWS’s scheduler is not public, so this could not be compared with the real service.

GitHub Actions

The rules in GitHub’s documentation and POSIX. GitHub’s scheduler is not public either.

Standard cron

The crontab man page and POSIX, with Vixie’s star rule taken from cronie’s source.

What is not calculated

• Where the documentation leaves a case undefined and implementations disagree, no run list is shown and the page says why. Examples are */2 beside the other day field on GitHub, and lists that mix L or W.
• Random ranges in cronie and one-time at() schedules have no predictable series.
• The runs are the times a schedule is due. Real schedulers add delay: GitHub can delay or drop runs at load, Kubernetes may skip or double a Job, and AWS Scheduler invokes within the minute.
• rate(), @every and Azure TimeSpan count from when they start, so their times are relative to the start time you choose.

Translation

Translations are rebuilt from the expanded values of each field, not by swapping text. Anything marked “Same schedule” has been checked by a test that compares the run times across dialects. It does not mean the schedule behaves the same at a clock change, because schedulers differ there. That is shown separately.

Found something wrong?

Sources for every rule are on each dialect’s page. Please compare the case with your scheduler first, since behaviour varies by version. Then email [email protected] with the expression, dialect and zone.