Cron Expression Validator
Validate five-field Unix cron expressions and inspect field values, day interactions, impossible dates, and scheduler limits.
Field order: minute hour day-of-month month day-of-week. Supported here: *, lists, forward ranges, steps on a wildcard/range, month aliases JAN–DEC, and weekday aliases SUN–SAT.
Field validation, selected-value expansion, day-field interaction and scheduler-boundary notes will appear here.
A Syntactically Valid Cron Expression Can Still Schedule the Wrong Work
Cron validation starts with field grammar, but production failures often happen one layer later. A schedule can be syntactically accepted and still run sixty times more often than intended, use the scheduler's unexpected timezone, collide with a previous run, or depend on a day-of-month/day-of-week rule the author remembered incorrectly.
Selected field values are expanded so schedule semantics remain visible instead of stopping at “five fields found.”
Day-of-Month and Day-of-Week Are the Cron Trap Worth Memorizing
0 9 15 * MON
In traditional Vixie/Cronie-style cron, when both day fields are restricted, the job is generally triggered when the day of month matches or the day of week matches. The expression above is therefore not naturally read as “only when the 15th is Monday.”
Other schedulers can define their own grammar or day semantics. Whenever both fields are restricted, verify the exact scheduler rather than translating the English requirement by intuition.
“Cron” Is a Family of Dialects, Not One Universal Grammar
Traditional system cron commonly uses five time/date fields. Quartz-style expressions add fields and operators such as ?, L, W and #. Some cloud schedulers add a year field. Cronie has extensions such as random ranges. Kubernetes and CI platforms document their own accepted syntax and timezone behavior.
A validator that accepts every symbol used by any of those systems is not “more compatible”; it can accidentally approve an expression that your real scheduler rejects. The accepted grammar is therefore a deliberately portable five-field subset; vendor-specific tokens are rejected rather than guessed.
Steps Have a Base—They Are Not Just “Every N” Attached Anywhere
*/15 means step through the full minute field by 15.0-45/15 steps through an explicit range. A form such as 5/15 is interpreted differently or rejected across cron implementations and is outside this portable subset.
If you mean minute 5, write 5. If you mean every 15 minutes, write */15. If you mean a bounded stepped range, write the range explicitly.
Calendar Syntax Can Describe Dates That Never Exist
Numeric range validation alone says that day 31 is legal and February is legal. The pair 31 2 still has no calendar date. Restricted day-of-month values are checked against selected months, with a warning when a selected day cannot occur.
February 29 is kept possible because leap years exist. No specific future year is invented merely to mark a legal leap-day schedule as broken.
DST Can Create a Missing Run or a Repeated Local Time
A local clock can jump forward over a scheduled time when daylight saving begins, or repeat a local time when daylight saving ends. Different cron implementations document how jobs inside those gaps and repeated ranges are handled.
If “run exactly once every elapsed 24 hours” is the real requirement, a local-time cron schedule may be the wrong abstraction. If “run at 02:30 local business time” is the requirement, document the DST expectation explicitly.
The Command Environment Is Separate From the Schedule
A correct schedule does not guarantee a successful job. Traditional cron runs commands with a smaller environment than an interactive shell, and production jobs can depend on PATH, HOME, credentials, working directory, shell choice, file permissions and service accounts.
Use absolute paths where appropriate, capture diagnostic logs, test the command under the same account/environment, and consider locking or idempotency when a previous execution can overlap the next one.
High Frequency Is an Operational Property, Not a Syntax Error
* * * * * is a perfectly recognizable five-field cron expression. It also asks for a run every matching minute. That may be correct for a tiny health check and disastrous for a backup, billing task, email sender or long-running batch job.
That frequency is reported as a warning instead of making the expression invalid. Syntax validators should not silently turn operational judgment into grammar.