minute · hour · day-of-month · month · day-of-week
Description
Every 5 minutes
Next 8 runs
- 1.5/11/2026, 6:10:00 PM
- 2.5/11/2026, 6:15:00 PM
- 3.5/11/2026, 6:20:00 PM
- 4.5/11/2026, 6:25:00 PM
- 5.5/11/2026, 6:30:00 PM
- 6.5/11/2026, 6:35:00 PM
- 7.5/11/2026, 6:40:00 PM
- 8.5/11/2026, 6:45:00 PM
About Cron Expression Parser
Cron Expression Parser turns a five- or six-field cron expression into a plain-English description and lists the next ten run times so you can sanity-check the schedule before deploying it. Standard `crontab(5)` syntax is supported, including step values (`*/15`), ranges (`9-17`), lists (`MON,WED,FRI`), named months and weekdays, and the optional seconds field used by Quartz / Spring schedulers.
Reach for it whenever an existing cron expression is opaque: a deploy hook, a Kubernetes CronJob, a GitHub Actions schedule, or a CI nightly that fires at the wrong moment. Parsing the expression in plain English ("Every 15 minutes between 9 and 17 on weekdays") and seeing the actual next run timestamps catches off-by-one mistakes that the raw `0 */15 9-17 * * 1-5` cannot. To build a new expression visually rather than read an existing one, use Cron Expression Generator — they are inverse tools.
Examples
*/15 9-17 * * 1-5Every 15 minutes from 09:00 to 17:00 on weekdays.
Next runs (UTC):
2026-05-05 14:15
2026-05-05 14:30
2026-05-05 14:45Five-field cron — minute / hour / day / month / weekday. Add a leading seconds field for Quartz-style six-field expressions.
Frequently asked questions
Which cron syntax is supported?
Standard Unix `crontab(5)` (five fields: minute / hour / day-of-month / month / day-of-week) and the Quartz / Spring six-field variant with a leading seconds field. Named months (`JAN`–`DEC`) and weekdays (`SUN`–`SAT`) are accepted in any case.
What timezone are the next runs in?
UTC by default, with a toggle to view them in your local timezone. Cron itself is timezone-naive — your scheduler's configured timezone determines the actual run time, so always confirm which timezone the server is using.
How is this different from Cron Expression Generator?
Parser reads an existing expression and explains it. Generator builds a new expression from a visual UI. Use Parser to debug or document; use Generator to author. They round-trip: anything Generator produces, Parser can read.
Why do some expressions never fire?
A common pitfall: setting both day-of-month and day-of-week to non-`*` values means the schedule fires when *either* matches (cron's OR rule), not both. Another: `0 0 31 2 *` will never fire because February never has a 31st. The parser flags impossible schedules with a warning.