Cron Expression Builder & Tester
Build, validate, and explain cron schedules visually.
Build, validate, explain, and test cron expressions visually. Preview upcoming run times and generate ready-to-use snippets for Linux, Laravel, Node.js, GitHub Actions, and Kubernetes.
What is a cron expression?
A cron expression is a short, field-based string that tells a scheduler exactly when to run a recurring task — a backup script, a report, a cleanup job. It's the format used by Linux crontab, Laravel's task scheduler, Kubernetes CronJobs, GitHub Actions, and countless other tools.
A standard cron expression has five space-separated fields — minute, hour, day of month, month, and day of week — each describing when that part of the schedule should match. When every field matches the current moment, the job runs.
Cron expression field explanation
| Field | Allowed values | Special characters |
|---|---|---|
| Minute | 0–59 | * , - / |
| Hour | 0–23 | * , - / |
| Day of month | 1–31 | * , - / |
| Month | 1–12 or JAN–DEC | * , - / |
| Day of week | 0–7 or SUN–SAT (0 and 7 both mean Sunday) | * , - / |
An optional 6th leading field for seconds (0–59) is supported by some platforms — Node.js/node-cron in this builder — and can be turned on from the tool above.
How to use the builder
- 1. Start from a preset or build from scratch. Pick a quick preset like “Every weekday” or “Business hours,” or leave it on the default and configure each field yourself.
- 2. Configure each field visually. Switch a field between every value, a specific value, multiple values, a range, a step, or a range with a step — named months and weekdays are available where it makes sense.
- 3. Or paste an existing expression. Type or paste a cron string into the manual input and the visual controls update to match it automatically.
- 4. Check the result panel. The generated expression, a plain-English explanation, validity, and the next 10 run times update instantly as you edit — no submit button required.
- 5. Pick a timezone and a target platform. Run times are calculated for the timezone you choose, and the platform snippet at the bottom is ready to paste into Linux crontab, Laravel, Node.js, GitHub Actions, or a Kubernetes CronJob.
- 6. Copy or share. Copy the expression or the platform snippet directly, or use the Share button to copy a URL that restores this exact schedule for a teammate.
Common cron expression examples
| Expression | Meaning | Action |
|---|---|---|
| */5 * * * * | Every 5 minutes | |
| 0 * * * * | Every hour | |
| 0 9 * * * | Daily at 9:00 AM | |
| 0 9 * * 1-5 | Every weekday at 9:00 AM | |
| 0 0 * * 0 | Every Sunday at midnight | |
| 0 0 1 * * | First day of every month | |
| */15 9-17 * * 1-5 | Every 15 minutes during business hours |
Cron syntax reference
| Syntax | Meaning |
|---|---|
| * | Every value in the field |
| , | A list, e.g. 1,15,30 |
| - | A range, e.g. 9-17 |
| / | A step, e.g. */15 or 9-17/2 |
| 0 and 7 (day of week) | Both mean Sunday |
Quartz-style tokens (L, W, ?, #) used by some Java schedulers aren't part of standard cron and aren't supported by this builder.
Platform compatibility notes
Linux Crontab
Standard 5-field cron. No native seconds field, and per-line timezone (CRON_TZ) support varies by cron daemon — confirm the server's configured timezone.
Laravel Scheduler
Ticks once a minute, so it works with 5-field expressions and a fluent ->timezone() call — a seconds field isn't meaningful here.
Node.js / node-cron
The only platform here that accepts an optional 6th (leading) seconds field, plus a timezone option.
GitHub Actions
5-field only, and schedule triggers always run in UTC regardless of the timezone you pick in this tool — convert the time yourself. Very frequent schedules can also be delayed under load.
Kubernetes CronJob
5-field schedule; the spec.timeZone field needs Kubernetes 1.27+ — omit it on older clusters and rely on the cluster's configured timezone.
Timezone and daylight-saving considerations
The builder defaults to your browser's detected timezone but lets you pick any IANA timezone — including UTC and commonly used zones like Asia/Karachi, Asia/Dubai, Europe/London, and America/New_York. Next-run previews are calculated for whichever zone you choose.
That preview is not the same as what actually runs your job. Most schedulers — Linux cron, Kubernetes, CI runners — execute in the server or cluster's configured timezone, which is commonly UTC unless set otherwise. GitHub Actions schedule triggers always run in UTC, full stop. Always confirm the effective timezone on the platform where the job will actually run.
Zones that observe daylight saving time shift their UTC offset twice a year. Around that transition, a schedule can run an hour earlier or later than usual, and — depending on the scheduler — a time inside the “spring forward” gap may be skipped entirely. The tool flags timezones that observe DST so you know when to double-check.
Common questions
Does this builder support Quartz syntax like L, W, ?, and #?+
No. This builder only supports standard Unix/Vixie cron syntax — wildcards, lists, ranges, and steps. Quartz-specific tokens (L, W, ?, #) used by some Java schedulers aren't implemented, and the builder will flag them as unsupported rather than silently accept them.
What happens if I restrict both day-of-month and day-of-week?+
Standard Unix cron treats them as OR, not AND — the job runs when either field matches, which can fire more often than expected. The tool shows a warning whenever both are restricted at once.
Can I write 0 or 7 for Sunday?+
Yes — both are accepted and treated as the same day. This matches standard cron behavior.
Which timezone actually runs my job?+
This tool calculates run times for the timezone you select here, but your scheduler ultimately uses whatever timezone it's configured with — often UTC or the server's system timezone. Always confirm that setting on the platform where the job actually runs.
Is my cron expression sent anywhere?+
No. Parsing, validation, next-run calculation, and snippet generation all happen locally in your browser with plain JavaScript — nothing is uploaded to a server.
Why does my schedule show a warning even though the expression is valid?+
Some expressions are technically valid but unusual or impossible — like day 31 in a month that never has 31 days, or February 29 outside leap years. The tool flags these separately from hard validation errors so you can catch them before deploying.
More free resources
Have a project in mind? Let's build it.
Tell us about your goals and we'll get back to you within one business day with next steps.
Book a free call