How to read a cron expression
Type a cron expression and the tool immediately rewrites it in plain English, breaks out each field, and lists the next six times it will fire in your local timezone — concrete proof that you read the schedule correctly. Use the preset buttons for common patterns, then tweak a field and watch the description and run times update. It is built for the moment you are staring at a line like */15 9-17 * * 1-5 in a crontab or a CI config and want to be certain what it actually does before you ship it.
The five cron fields
A standard cron expression has five space-separated fields, read left to right:
- Minute (0–59) — the minute of the hour.
- Hour (0–23) — the hour of the day, 24-hour clock.
- Day of month (1–31) — the calendar date.
- Month (1–12, or JAN–DEC) — the month of the year.
- Day of week (0–6, or SUN–SAT, with 7 also meaning Sunday) — the weekday.
A job runs when the current time matches all the active fields. So 30 2 * * * means "at 02:30 every day", because minute and hour are fixed while the date, month and weekday fields are wildcards that match anything.
Ranges, steps and lists
Each field can be more than a single number. An asterisk * matches every value. A range like 9-17 matches a span — here, the hours from 9am to 5pm. A step like */15 matches every fifteenth value (0, 15, 30, 45), and steps combine with ranges, so 0-30/10 means 0, 10, 20, 30. A list like 1,15,30 matches several specific values. The month and day-of-week fields also accept three-letter names — JAN, MON — which are often clearer than numbers. Combining these covers almost every real schedule: */15 9-17 * * 1-5 reads as "every 15 minutes between 9am and 5pm, Monday to Friday".
Day-of-month vs day-of-week
The one genuine trap in cron is how the two day fields interact. When both day-of-month and day-of-week are restricted (neither is *), the job runs when either matches — not both. So 0 0 13 * 5 fires on the 13th of the month and on every Friday, not only on Friday the 13th. This OR behaviour, inherited from the classic Vixie cron, surprises people constantly; this tool applies it correctly and the next-run list makes the real effect obvious, so you catch the mistake before it reaches production.
Why parse cron locally
Reading a cron schedule is a deterministic calculation, which makes a real tool far safer than asking an AI assistant to "explain this cron line" — a model can quietly invert the day-field rule or miscount a step and state it with confidence, and a wrong schedule means a job that never runs or runs at the wrong time. This parser applies the algorithm exactly and shows you the concrete next runs. It is instant, works offline, and your expressions — which can hint at infrastructure details — never leave the browser, matching the gitime.dev default that nothing is uploaded.
- Plain-English translation of any 5-field expression.
- Next six runs in your local timezone.
- Full syntax — ranges, steps, lists, names.
- Correct day-field OR semantics.
- Local — exact, instant, nothing uploaded.
Frequently asked questions
- What cron format does it use?
- Standard five fields: minute, hour, day-of-month, month, day-of-week, with *, ranges, steps, lists and names.
- What timezone are the run times in?
- Your browser's local timezone — adjust if your cron daemon runs in UTC or another zone.
- How are the two day fields combined?
- If both are restricted, the job runs when either matches (Vixie cron OR rule); if one is *, only the other applies.
- Is anything uploaded?
- No. All parsing and next-run calculation run locally in your browser.