How to generate a schedule
Choose a preset or enter your own five fields, select the scheduler, and type an IANA time zone. Generate refreshes the expression and the next matching dates from the current instant. Editing a setting clears the previous result so you cannot accidentally copy a schedule that belongs to older inputs. The weekday preset uses minute seventeen to avoid putting every example on the hour.
Copy exports the expression for Linux or the schedule trigger fragment for GitHub Actions. Download saves the same text. The GitHub fragment belongs inside a workflow that also defines jobs; it is not a complete runnable workflow. Linux output contains only the five timing fields: append your own command in a user crontab and configure its scheduling timezone in the cron implementation. Selecting a timezone here does not change your server.
Understand the five cron fields
The fields are minute, hour, day of month, month, and weekday. An asterisk allows every value. Commas build lists, a hyphen includes both ends of a range, and a slash supplies a step. For example, */15 9-17 * * MON-FRI means quarter-hour matching times within the listed working hours. A step resets within its own field; it does not mean a rolling elapsed duration from the last execution.
Month names JAN through DEC and weekday names SUN through SAT are accepted without regard to letter case. Sunday can be zero or seven in the Linux profile; GitHub uses zero. Numeric day and month bounds are checked before searching dates. A syntactically valid expression can still describe an impossible calendar date. Seconds, years, Quartz question marks, L, W, hashes, and at-sign shortcuts are intentionally outside this tool.
Day fields and platform checks
Traditional cron combines restricted day-of-month and weekday fields with OR. Thus 0 9 1 * MON matches the first of each month and Mondays, rather than only Mondays that happen to be the first. If either day field begins with an asterisk, matching applies both field conditions. This distinction also affects stepped wildcard fields. Leave one day field unrestricted when your intention is straightforward monthly or weekly scheduling.
The GitHub profile rejects less than five minutes between selected clock times, including the midnight wrap. The midnight check also verifies whether the calendar permits consecutive matching dates. It checks nominal clock spacing, not a promise that a hosted runner will start at that interval. GitHub schedules use the default branch and may be delayed or dropped under load. Public repository schedules can be disabled after sixty days without activity.
Time zones, DST and preview limits
The selected timezone is the scheduling timezone, not merely a different display of a UTC expression. UTC avoids seasonal clock changes. Europe/Istanbul currently keeps the same UTC offset throughout the year, while other regions can change offset. Each result includes an absolute UTC timestamp so repeated local clock readings remain distinguishable. Browser Intl timezone data supplies the conversion, and future political changes may require a browser update.
The search checks calendar days for at most eight years rather than scanning every minute across many years. A leap-day schedule may therefore return fewer than five dates with a visible warning. Missing Linux wall-clock times are skipped in this matching preview. GitHub documents advancing a spring-forward gap to the next valid time; this preview searches up to three hours for that boundary. Both matching instants appear during repeated hours. Cron daemons and hosted runners can apply other duplicate-run policies: inspect your actual scheduler before relying on DST behavior.
Privacy and operational follow-through
Expressions and settings are processed locally without contacting a scheduler. Sharing includes settings in the URL fragment only when you tick the option; anyone receiving that link can read them. Avoid putting secrets in schedules or commands. This page does not install a job, verify credentials, check workflow history, or monitor successful execution. After deployment, inspect logs, exit codes, overlapping jobs and retry handling. Consult the GitHub schedule documentation before production use.
Frequently asked questions
Does this create a running job?
No. It generates timing text and calculates matching dates locally. Install the output in your scheduler, add the actual command or workflow jobs, and check logs after the first execution.
Can GitHub Actions use a local timezone?
Yes. Current GitHub documentation allows an optional IANA timezone beside cron. Without it the default is UTC. The generated snippet includes timezone when you select a non-UTC zone.
Why are fewer than five dates shown?
The preview searches eight calendar years. Very sparse schedules, including leap days, can have fewer matches within that window. This is a search boundary rather than proof the expression will never match again.
Why did my scheduled job start late?
A matching clock time does not reserve computing capacity. Runner queues, disabled workflows, server outages, permissions and job failures can affect execution. Inspect scheduler logs and platform status separately.
Is this compatible with every cron dialect?
No. This tool supports standard five-field expressions and the described profiles. Quartz, seconds fields, system-crontab usernames and implementation-specific DST policies require separate review.