Cron expression validator
Checks syntax field by field and warns about the schedules that are valid but don’t do what you think.
✕ Invalid
hour: Hour "24" is out of range (0–23).
Try a broken one:
What the validator checks
| Check | Example | Result |
|---|---|---|
| Field count for the dialect | */5 * * * * * in Unix mode | Error: six fields is Quartz syntax |
| Value ranges | 0 24 * * * | Error: hour must be 0–23 |
| Names and symbols | 0 9 * * ? in Unix mode | Error: “?” is Quartz/AWS only |
| Backwards ranges | 0 17-9 * * * | Error: use 0 17-23,0-9 * * * |
| Day-of-month OR day-of-week | 0 0 13 * 5 | Warning: fires on every 13th and every Friday |
| Uneven steps | */7 * * * * | Warning: gap of 4 minutes at the top of each hour |
| Days that don’t exist | 0 0 31 2 * | Warning: never fires |
| Quartz/AWS “?” rule | 0 10 * * * * in AWS mode | Error: one day field must be “?” |
Questions
What makes a cron expression invalid?
The wrong number of fields, a value outside its range (minute 60, hour 24, month 13), an unknown name, a backwards range like 17-9, or a symbol your cron flavour does not support, such as "?" or L in standard crontab.
My expression is valid but runs at the wrong time. Why?
The usual causes are the time zone (the server or service may use UTC), a minute left as * so it fires every minute, or both day fields set, which makes standard cron fire when either matches. The validator flags the last two as warnings.
Does it test the expression against my server?
No. It checks the syntax and computes run times in your browser using the rules of the chosen dialect. Implementations differ slightly (for example some reject 7 for Sunday), so confirm on the system that runs the job.
What does the AI fix do?
It sends the broken expression and the validator’s message to an AI model, which proposes the expression you most likely meant. The suggestion is re-checked by the validator before you can use it.