About Cron Expression Parser

A cron parser explains 5-field cron expressions, showing minute, hour, day, month, and weekday fields plus upcoming run times.

Use it to check crontab entries, scheduled jobs, CI schedules, and background workers.

How to use the Cron Parser

Paste a 5-field cron expression such as */15 9-18 * * 1-5.
Read the field summary and range validation.
Check whether upcoming run times match the intended schedule.

When you would use it

Confirm a job runs only during weekday business hours.
Debug midnight, month-end, or weekday-field mistakes.
Explain a production crontab entry to teammates.

Cron field order and common syntax

This tool parses common 5-field cron: minute hour day month weekday. Some platforms add seconds, year, ?, or @daily shortcuts, so migrations should follow the target scheduler docs.

* means any value.
*/15 means every 15 units.
1-5 is a range, while 1,3,5 is a list.
When day-of-month and weekday are both restricted, cron implementations may combine them differently.

Cron Parser FAQ

Is this 5-field or 6-field cron?: This parser uses 5-field crontab syntax: minute hour day month weekday, without seconds.
Why does the next run differ from production?: Common causes are timezone, platform-specific extensions, or different day/month/weekday combination rules.
Is my expression uploaded?: No. Parsing and preview run locally in the browser and are not uploaded to wetool.site.

Cron Parser vs schedulers

A parser helps you understand an expression, but it is not the scheduler used by Kubernetes, GitHub Actions, Quartz, or Linux crontab. Validate against the target platform before shipping.

5-field, 6-field, and Quartz cron differences

Cron mistakes often come from the target platform field order, not from the asterisk itself.

Linux crontab commonly uses 5 fields: minute, hour, day-of-month, month, day-of-week.
Quartz, Spring, and some cloud schedulers add seconds or year and support extensions such as ?, L, W, and #.
GitHub Actions, Kubernetes, Vercel, and similar platforms may force UTC or apply their own schedule limits.

Timezone, DST, and month-end debugging

When previewing next runs, confirm the platform timezone. Daylight saving time, month-end, and weekday/day-of-month combinations cause many production surprises.

If the platform runs in UTC, local 09:00 may need conversion before deployment.
DST transition days can skip or duplicate runs, so critical jobs should avoid boundary hours.
When both day-of-month and day-of-week are restricted, cron implementations may use OR or AND semantics.