Cron Expression Parser
Paste a cron expression and get a human-readable schedule plus the next run times in your local timezone. Supports standard 5-field crontab and optional seconds.
Expression
—
What does my cron expression actually mean?
What this tool does
Paste a cron string and get two things immediately: a plain-English description of the schedule and a list of upcoming run times in your local timezone. Field breakdowns show how each position (minute, hour, day, month, weekday) contributes, and presets help you start from common patterns like “every 15 minutes” or “weekdays at 9 AM.”
Why you need it
Cron syntax is compact but easy to misread. One stray asterisk can turn “once a day” into “every minute.” CI pipelines, backup jobs, Kubernetes CronJobs and server crontabs all rely on the same five-field pattern, yet teams still ship typos because the field order is not intuitive. Before you deploy a schedule that runs billing at 3 AM instead of 3 PM, or fires every hour when you meant weekly, a parser saves a production surprise.
How to use it
- Paste your expression into the input or click a preset / Load sample.
- Read the Meaning box — that is the schedule in everyday language.
- Review the per-field breakdown to see which positions are restricted.
- Check Next runs (5, 10 or 20) to confirm timing in your local timezone.
- Copy description into runbooks, pull requests or ticket comments.
Practical examples
- CI nightly builds: Validate
0 2 * * *runs at 02:00, not every two minutes. - Backup windows: Confirm
30 1 * * 0is Sunday 01:30 local before touching production data. - Staggered polling: Use
*/15 * * * *for quarter-hour checks; compare next runs against peak traffic. - On-call handoff: Paste a teammate’s crontab entry and explain it in plain English during review.
How it works
Standard cron uses five space-separated fields: minute (0–59), hour (0–23), day of month (1–31), month (1–12), day of week (0–6, Sunday = 0). An optional sixth field adds seconds for schedulers that support sub-minute precision.
Special characters carry the real power. * means “every value.” , lists alternatives (1,15,30). - defines ranges (9-17 for business hours). / sets steps: */15 in the minute field fires every 15 minutes. When both day-of-month and weekday are restricted, classic crontab treats them as OR — the job runs if either matches, which surprises people expecting AND logic.
Next-run calculation walks forward from “now” in your browser’s local timezone, respecting DST shifts at each candidate instant. Everything stays on your device — nothing is posted to a server.
Common mistakes
- Wrong field order: Minute comes first.
0 9 * * *is 09:00 daily; swapping fields silently changes meaning. - Ranges vs steps:
1-5/2is not the same as1,3,5on every engine — test with next runs. - Over-broad minutes:
* * * * *runs every minute; a single*in minute with a fixed hour still runs 60 times that hour if other fields are wildcards. - Day + weekday confusion: Restricting both
15andMonmay run on the 15th or every Monday, not only when both align. - Timezone assumptions: Cloud schedulers often use UTC; next runs here reflect local time — translate before comparing to AWS EventBridge or GitHub Actions defaults.
FAQ
What format does this parser expect?
Standard 5-field cron (minute hour day month weekday). Optional 6-field expressions with seconds are also supported.
How are day-of-month and weekday combined?
Like classic crontab: if both are restricted, the job runs when either field matches (OR).
Are next runs in my local timezone?
Yes. Next run times use your browser's local timezone.
What is the difference between */5 and 0/5 in a field?
In many parsers */5 means every 5 units through the full range. Step syntax like 0/5 starts at 0 and steps by 5. Always confirm against your scheduler's docs — cloud cron services differ slightly.
Why does my job run more often than I expect?
Common causes: using * in the minute field when you meant hourly, OR logic between day-of-month and weekday, or confusing 5-field order (minute first, not seconds).
Is my cron expression sent to a server?
No. Parsing and next-run calculation happen entirely in your browser.