Cron Expression Builder for Five-Field Schedules
Build and inspect a five-field cron expression. Review the field values and next-run preview before copying the schedule.
Cron Expression Builder & Tester workspace
Valid schedule
Every 5 minutes
- Calculating upcoming run times…
Quick Presets
Next 5 Fire Times
Computed from your local clock so you can immediately verify whether the schedule lines up with your intent — no mental math, no surprises in staging.
Per-Field Validation
If any of the five fields is invalid, we tell you which one and why. Catches off-by-one ranges, illegal steps, and month/weekday name typos.
12 Common Presets
One-click templates for the schedules you actually use — every 5 minutes, hourly, daily at 9, weekdays, monthly-on-the-first, quarterly, yearly.
100% Client-Side
Parsing, validation, and next-fire calculation all run in your browser. Your scheduling logic stays local — no server logs, no analytics on the expression.
Cron Expression Builder: Test Any Schedule Against Real Fire Times
Build and inspect a five-field cron expression. Review the field values and next-run preview before copying the schedule. Cron implementations differ in timezone handling, day matching, and supported extensions. A five-field expression is not interchangeable with every scheduler's syntax. Verify the expression and timezone in the scheduler that will execute the job.
How to use the cron expression builder
- Pick the closest preset (every 5 minutes, daily at 9, weekdays, monthly, quarterly) to skip blank-page syntax recall.
- Edit the five fields directly — use
*for "any",,for lists,-for ranges, and/for steps. - Read the plain-English description to confirm the schedule matches your intent.
- Check the next five fire times, shown in your browser local timezone, for any weekday or day-of-month edge case.
- Convert to UTC if your runner needs it, then paste the expression into your crontab or workflow file.
What is cron and how the fields work
The cron daemon dates to Version 7 UNIX (1979), and the field format most systems use today was standardized by Paul Vixie in 1987. A standard expression has exactly five fields read left to right: minute 0-59, hour 0-23, day-of-month 1-31, month 1-12 (or JAN-DEC), and day-of-week 0-6 (or SUN-SAT, where both 0 and 7 mean Sunday). The behaviour is defined in the POSIX crontab specification (IEEE Std 1003.1, The Open Group).
The most surprising spec rule governs the two day fields. When both day-of-month and day-of-week are restricted (neither is *), cron uses OR logic, not AND. The POSIX text states the job runs when either the day-of-month or the day-of-week field matches the current day. This builder follows that rule exactly — so 0 0 1 * MON fires on the 1st of every month and on every Monday.
Worked examples: expression → meaning
Every 15 minutes
*/15 * * * * → fires at :00, :15, :30, :45 of every hour
Weekdays at 9 AM
0 9 * * 1-5 → minute 0, hour 9, Monday through Friday
Step from an anchor
5/10 * * * * → minute 5, then every 10th: :05, :15, :25, :35, :45, :55 (n/p runs from n to the field max)
Edge case · the timezone gotcha
0 9 * * 1-5 on GitHub Actions or Vercel fires at 9:00 AM UTC, which is 4:00 or 5:00 AM US Eastern depending on daylight saving — cloud runners ignore your local clock. This builder shows fire times in your browser local timezone, so subtract your UTC offset before pasting into a workflow file.
Cron field reference
The five fields and their allowed values, in order. All five accept *, ,, -, and /.
| Position | Field | Allowed values | Aliases |
|---|---|---|---|
| 1 | Minute | 0–59 | — |
| 2 | Hour | 0–23 | — |
| 3 | Day of month | 1–31 | — |
| 4 | Month | 1–12 | JAN…DEC |
| 5 | Day of week | 0–6 (Sun=0) | SUN…SAT |
| Character | Meaning | Example |
|---|---|---|
| * | All values in the field | * * * * * = every minute |
| , | List of discrete values | 0 8,12,17 * * * = 8 AM, noon, 5 PM |
| - | Inclusive range | 9-17 = 9 through 17 |
| / | Step value | */5 = every 5th, 10-20/2 = 10,12,14,16,18,20 |
Out of scope for 5-field cron: macros like @daily, a leading seconds field, and the L, W, and # characters — those belong to Quartz and AWS EventBridge. Quartz adds seconds at the front and an optional year at the end; AWS EventBridge adds a year and requires ?in either the day-of-month or day-of-week field.
The one-year horizon most testers do not mention
The next-fire engine advances one minute at a time and stops after 366 days(60 × 24 × 366 = 527,040 minutes). For everyday schedules that is invisible. But a rare expression like 0 0 29 2 * (midnight on Feb 29) can return fewer than five upcoming times — leap days are more than a year apart, so the scan hits its cap before finding them all. That is a deliberate guard against runaway loops, not a bug.
Two other behaviours worth knowing: the day-of-week field normalizes 7 to Sunday, and a wrap-around range such as 5-1 in that field is expanded to Friday, Saturday, Sunday, Monday — a convenience that pure Vixie cron does not always accept.
Related developer & scheduling tools
Convert Unix time to local for UTC offsets
Timezone ConverterTranslate a local schedule to UTC
UUID GeneratorTag each scheduled run with a correlation ID
Regex TesterValidate log patterns from scheduled jobs
JSON FormatterInspect job payloads and config
Number Base ConverterDecode hex and octal exit codes
HTTP Status CodesLook up codes from scheduled API checks
Hash GeneratorChecksum artifacts produced by a job
HMAC GeneratorSign webhook payloads from triggers
Random Number GeneratorJitter retry delays for scheduled tasks
Nginx Config GeneratorDeploy scheduled apps behind a production reverse proxy
All ToolsBrowse the full Toolk utility hub
Last updated: September 15, 2026 · Runs 100% in your browser — no uploads, tool input is not sent to Toolk.
Frequently asked questions
Why does my GitHub Actions schedule run at the wrong hour?
Cloud runners interpret cron in UTC, not your local clock — 0 9 * * 1-5 fires at 9:00 AM UTC, which is early morning in US Eastern and shifts again with daylight saving. This builder shows the next fire times in your browser's timezone so you can subtract the offset before pasting.
Why does 0 0 1 * MON fire on more days than I expected?
When both day-of-month and day-of-week are restricted, POSIX cron applies OR logic, not AND — the job runs if either field matches. So that expression runs on the 1st of every month and additionally on every Monday; the builder follows this spec rule exactly.
Can I use names like JAN or FRI instead of numbers?
Yes. Months accept JAN through DEC and weekdays accept SUN through SAT, case-insensitively, plus ranges, lists, and steps. 0 17 * * FRI is identical to 0 17 * * 5 — every Friday at 5 PM.
Why does Feb 29 show fewer than five next fire times?
The next-fire engine advances one minute at a time and stops after 366 days as a guard against runaway loops. Because leap days sit more than a year apart, an expression like 0 0 29 2 * legitimately exhausts the scan window before filling all five slots.
Is my schedule data sent anywhere while testing?
No. Parsing, validation, the plain-English description, and the fire-time scan are processed locally in your browser, and Toolk's page analytics do not receive your expressions. Tool input is not sent to Toolk.