Cron Expression Parser
Paste a cron expression to get a plain-English description, a minute, hour, day, month and weekday breakdown, and a clear error if a field is out of range.
What it does
- Plain-English description of the full schedule
- Field-by-field breakdown: minute, hour, day of month, month, day of week
- Validation with the exact field and value that is wrong
- Six quick examples for common schedules
- Runs in the browser, no data sent to any server
*
Minute
*
Hour
*
Day (M)
*
Month
*
Day (W)
Quick examples
This cron expression parser reads a standard 5-field cron expression and tells you, in plain English, when it fires. Paste 0 9 * * 1-5 and you get "At minute 0, hour 9, on Monday through Friday", plus a breakdown of each field. If a value is out of range, the parser names the field and the bad token (for example "Invalid value in hour: 24") instead of silently accepting it. Parsing runs in a Rust module compiled to WebAssembly in your browser.
How to parse a cron expression
- Paste or type the expression into the Cron expression field. The page loads with
*/15 * * * *already parsed as an example. - Press Enter or click Parse.
- Read the description at the top of the result, then check the five boxes below it: Minute, Hour, Day (M) for day of month, Month, and Day (W) for day of week.
- To start from a known pattern, click one of the quick examples (every minute, every hour, daily at midnight, Monday at 9 AM, every 15 minutes, first of the month) and edit it.
The five cron fields
A crontab line is five fields separated by spaces, followed by the command. This parser reads the five schedule fields:
| Position | Field | Allowed values |
|---|---|---|
| 1 | Minute | 0 to 59 |
| 2 | Hour | 0 to 23 |
| 3 | Day of month | 1 to 31 |
| 4 | Month | 1 to 12 |
| 5 | Day of week | 0 to 6 (0 is Sunday; 7 is also accepted as Sunday in a list) |
Supported syntax
*wildcard: every value of the field.*/nstep: every n units, such as*/15in minutes or*/6in hours ("At minute 0, every 6 hours").a-brange:9-17in hours,1-5in day of week (Monday through Friday).a,b,clist:1,15in day of month for the 1st and 15th.a-b/nstep on a range:0-30/5in minutes. Accepted in the minute, hour and day-of-month fields.
Month and weekday numbers are translated to names in the description, so 0 0 * * 0 reads "on Sunday" and a month of 3 reads "in March".
What this parser does not cover
Cron has many dialects, and the parser sticks to the classic 5-field form used by crontab, Kubernetes CronJobs and GitHub Actions schedule triggers. Knowing the limits avoids false confidence:
- No seconds or year field: 6 and 7-field expressions from Quartz or Spring (
0 0 12 * * ?) are rejected with "expected 5 fields". - No names or macros:
MON,JAN,@dailyand@rebootare not recognized. Use the numeric form (1,1,0 0 * * *). - No special characters: Quartz extensions
L,W,#and?are not supported. - No next-run list or timezone: the tool describes the pattern, it does not compute upcoming dates. Cron fires in the timezone of the machine or service running it, often UTC on cloud schedulers, so
0 9 * * *may mean 9:00 UTC, not 9:00 local time. - Day of month plus day of week: when both fields are restricted, classic cron runs the job when either one matches, not both. The description lists both conditions side by side, so read
0 0 13 * 5as "the 13th, or any Friday". - English descriptions: the generated sentence is always in English.
Typical uses
- Code review: check a schedule in a pull request before it merges, instead of decoding
*/15 9-17 * * 1-5by eye. - Inherited crontabs: explain lines on a legacy server before changing or removing them.
- Catching invalid values: hour
24, month13or step*/0fail with a precise message, so you find the mistake before the scheduler does. - Documentation: copy the English description into a runbook or a comment next to the cron line.
Compared with the command line
On Linux, crontab -e validates syntax only when you save, and the error message rarely says which field is wrong. Reading man 5 crontab explains the format but not your specific line. Some schedulers show the next run after deployment, which is too late to catch a typo. A parser in the browser gives you the reading before anything is deployed.
Why parse cron expressions locally
Crontabs reveal when backups run, when batch jobs touch production databases and when maintenance windows open. That timing is useful to an attacker. Here the expression is parsed by WebAssembly inside your tab and is never sent to a server or stored. The page works offline once loaded.
Frequently asked questions
- What does
*/15 * * * *mean? - Every 15 minutes: at minutes 0, 15, 30 and 45 of every hour, every day.
- How do I run a job every weekday at 9 AM?
- Use
0 9 * * 1-5. The parser describes it as "At minute 0, hour 9, on Monday through Friday". Remember that 9 is in the timezone of the machine running cron. - Is Sunday 0 or 7?
- Both are common. This parser treats
0as Sunday and also accepts7as Sunday when it appears alone or in a list such as1,7. Inside a range, use0:1-7is rejected. - Why is my 6-field expression rejected?
- A sixth field is usually seconds (Quartz, Spring) or a year. The parser only reads the standard 5-field format. Drop the seconds field to check the rest of the schedule.
- Can I use
@dailyorMON-FRI? - No. Write
0 0 * * *for daily and1-5for Monday to Friday. - Does it show the next run times?
- No. It explains the pattern field by field. To convert a run time you found in a log into a readable date, use a timestamp converter.
- Is my cron expression sent anywhere?
- No. Parsing happens entirely in your browser via WebAssembly.
Related tools: when a job log records Unix epoch values, the Unix timestamp converter turns them into UTC dates so you can match runs against the schedule. For CronJob manifests or CI configs, the YAML, JSON and TOML converter helps reshape the surrounding config, and the regex tester is handy for checking patterns in scripts that grep cron output.