Cron Expression Parser — Validate, Explain, and Preview Schedules
Enter a standard five-field cron expression and instantly see a plain-English explanation, field breakdown, and the next scheduled run times in UTC.
Valid expression
Runs at 09:00 on Monday through Friday.
Minute
0
0
Hour
9
9
Day of Month
*
1, 2, 3, 4, 5... (31 values)
Month
*
1, 2, 3, 4, 5... (12 values)
Day of Week
1-5
1, 2, 3, 4, 5
What Is a Cron Expression?
Cron is the time-based job scheduler in Unix-like systems. A cron expression defines when a job should run using five fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 mean Sunday).
Each field can be a specific value (5), a range (9-17), a list (1,3,5), a step (*/15), or a wildcard (*). Combining these lets you express virtually any recurring schedule — from "every minute" to "at 9:00 AM on the first Monday of every quarter."
The syntax is powerful but easy to misread. "0 */2 * * *" runs every 2 hours, not every 2 minutes. "0 9 * * 1-5" runs weekdays at 9 AM, but "* 9 * * 1-5" runs every minute during the 9 AM hour on weekdays (60 times!). This parser shows you exactly what your expression means.
How to Use
- Type or paste a five-field cron expression into the input box.
- Or click a preset button to fill in common schedules (every hour, weekdays at 9, etc).
- Read the plain-English description to confirm it matches your intent.
- Check the field breakdown to see exactly which values each field expands to.
- Review the next 5 run times to verify the schedule against your expectations.
When You Need This
Writing crontab entries
Before adding a schedule to your crontab or CI config, paste it here to confirm it does what you think. Saves you from deploying a job that runs 60x more often than intended.
Debugging scheduled jobs
A job didn't run when expected. Paste the cron expression and check the next run times against the timezone your server uses. Often the issue is UTC vs local time.
Documenting team schedules
Sharing a cron expression in a PR or wiki? Paste the human-readable explanation alongside it so reviewers don't have to decode "0 */4 * * 1-5" in their heads.
Learning cron syntax
Experiment with different expressions and see the results instantly. Better than reading man pages when you're learning the step and range syntax.
Tips
Always verify the timezone
This tool shows next run times in UTC. If your server runs in a different timezone, adjust accordingly. Many production bugs come from timezone confusion in cron schedules.
Prefer explicit times over short intervals
"*/5 * * * *" (every 5 minutes) is fine for health checks, but for business logic prefer specific times like "0 9,17 * * *" (9 AM and 5 PM). It's easier to reason about and less likely to cause load spikes.
Test edge cases around month boundaries
"0 0 31 * *" runs only in months with 31 days — January, March, May, July, August, October, December. If you need "last day of month," use a different approach.
Document your expressions
In your codebase, always add a comment explaining the schedule in plain English. Future maintainers (including you in 6 months) will appreciate it.
Examples
Weekdays at 9 AM
The classic office-hours schedule.
Input
0 9 * * 1-5Output
Runs at 09:00 on Monday through Friday.Every 15 minutes
Common for monitoring and health checks.
Input
*/15 * * * *Output
Runs every 15 minutes on every day.Limitations
- Supports standard 5-field cron only (minute, hour, day-of-month, month, day-of-week). Does not parse 6-field (with seconds) or 7-field (with year) formats.
- Next run times are calculated in UTC. If your server runs in a different timezone, you need to manually adjust.
- Does not support non-standard extensions like L (last), W (weekday), or # (nth weekday) used by Quartz scheduler.
- Cannot validate whether a cron expression is actually deployed or running — it only parses the syntax.
Features
- Instant validation with clear error messages
- Plain-English description of the schedule
- Field-by-field breakdown showing expanded values
- Next 5 run times calculated in UTC
- Common preset buttons for quick entry
- No server calls — runs entirely in your browser
FAQ
Does this support 6-field or 7-field cron expressions?
No. This tool supports the standard 5-field format (minute, hour, day-of-month, month, day-of-week). Some systems like Quartz add a seconds field or year field — those aren't supported here.
Why are the next run times in UTC?
UTC is unambiguous and avoids daylight saving time confusion. Most server-side cron systems run in UTC. If yours runs in local time, manually offset the displayed times.
Can I use day names like MON-FRI?
Not in this parser. Use numeric values: 1-5 for Monday through Friday. Some cron implementations support three-letter names, but the portable standard uses numbers only.
What does 0 and 7 both meaning Sunday?
It's a historical quirk. Different Unix systems used different conventions (0=Sunday vs 7=Sunday). Modern cron accepts both. This parser normalizes 7 to 0 internally.
How far ahead does it calculate run times?
Up to about 5 years ahead. If your expression is very sparse (like "0 0 29 2 *" — only runs on Feb 29), it might not find 5 results within that window.
Content last reviewed: June 2026
Your Privacy
All cron parsing happens entirely in your browser. No data is uploaded to any server. Your scheduling expressions never leave your device.
Tips & Related Workflows
- Need to convert between timezones for your schedule?Timezone Converter.
- Working with Unix timestamps in your cron jobs?Timestamp Converter.
- Calculating date differences for scheduling logic?Date Difference Calculator.