Cron Expression Parser
Schedule & Validate
Validate five-field cron expressions, read a plain-language summary, and preview the next five UTC run times.
This conversion runs only in your browser — nothing is uploaded.
- Fields…
Next runs are shown in UTC. Match your scheduler’s timezone before deploying.
What is this tool?
This cron expression parser validates five-field schedules (minute, hour, day of month, month, day of week) and optional six-field expressions with a leading seconds field. You get a plain-language summary, a field breakdown, and the next five run times in UTC.
Cron is compact but easy to misread. */5 means every five units, ranges such as 1-5 include both ends, and * means every allowed value. Different schedulers add seconds, years, time zones, or special tokens — always match the target platform.
Common use cases
- Preview CI / GitHub Actions or GitLab schedules before changing a pipeline
- Check Kubernetes CronJob or systemd timer expressions against wall-clock UTC
- Validate cleanup, report, and monitor jobs that should fire on weekdays only
How to use
- Enter or pick a five-field expression such as
0 9 * * 1-5(or six fields with leading seconds). Results update live. - Read the next five UTC runs at the top, then the summary sentence and field chips.
- Copy the summary plus run list into a runbook, ticket, or deployment note.
- Confirm your scheduler’s timezone (
TZ=, cluster local time, or UTC) before shipping.
Examples
| Input / setting | Output | Notes |
|---|---|---|
0 9 * * 1-5 | Weekday 09:00 UTC runs | Sample preset — Mon–Fri at minute 0 of hour 9. |
*/5 * * * * | Every 5 minutes | Step syntax on the minute field. |
0 * * * * | Top of every hour | Common “hourly at :00” preset. |
0 0 31 * * | Skips months without a 31st | Edge: Sep/Nov (and Feb) never match day 31. |
Practical pitfalls
- Timezone mismatch: this preview is UTC; a host running in local time will fire at a different wall clock.
- Five vs six fields: many libraries treat six fields as
sec min hour dom month dow. Pasting a five-field string into a six-field parser (or the reverse) shifts every column. - Day 31 skip (unique ops gotcha):
0 0 31 * *silently skips short months — use day 28 or last-day syntax where supported if you need “end of month.”
For a ready-made schedule, check cron every five minutes or weekdays at 9 AM. Both show the exact expression, variations and scheduler limits; this tool previews UTC, not your local job timezone.
References
Last reviewed: 2026-10-11
Task guides with ready-to-use settings
- Cron Every 5 Minutes — Expression & Next Runs
Use */5 * * * * in a five-field crontab to run at minutes 00, 05, 10 through 55 of every hour. It is tied to clock marks, not five minutes after deployment or completion. This preview uses UTC.
- Cron Weekdays at 9 AM — Monday to Friday
Use 0 9 * * 1-5 for 09:00 Monday through Friday in a five-field crontab. It excludes weekends, but not public holidays. The preview below uses UTC; configure your scheduler's timezone for local 9 AM.
Frequently asked questions
- Which cron format is supported?
- Five fields — minute, hour, day of month, month, day of week — or six when you add a leading seconds field. Quartz-style year fields and most `@yearly` macros are outside this tool’s focus; stick to numeric five/six-field expressions used by crontab, CI, and Kubernetes CronJobs.
- What time zone are next runs shown in?
- Next run times are labeled in UTC. Your production scheduler may use local time, `TZ=`, or a container timezone — align those before deploying or the wall-clock time will disagree with this preview.
- Why does 0 0 31 * * skip some months?
- Day-of-month 31 only exists in months that have 31 days. Schedulers skip invalid dates, so September and November never fire for that expression. Prefer L (last day) on platforms that support it, or pick a safer day such as 28.
- Does parsing require a server?
- No. Cron parsing and next-run math run entirely in your browser; the expression is not uploaded.