Crontab Syntax Checker

Crontab Syntax Checker: Validate Your Cron Expression

A cron line can look correct and still be wrong. A misconfigured expression is silently accepted and either runs at the wrong time or never runs at all.¹ Checking syntax before deployment is the only reliable way to catch errors; an out-of-range value (like 60 in the minute field) or a misplaced operator (*/0 as a step) will not warn you, and the daemon simply ignores or misinterprets the line.²

The fastest check is a browser-based parser like this one: paste the expression and read the English description or the next 5 run times. If the description says something different from your intent, the expression is wrong before any code is deployed. More thorough checks involve running the expression through a shell command on the target system or using the systemd-analyze calendar command as a cross-reference.

### Choosing the right validation tool

Common crontab syntax errors

The most frequent mistakes are: using 60 in the minute field (valid range 0 to 59), using 24 in the hour field (valid range 0 to 23), a step of 0 like */0 (undefined behavior), combining both day-of-month and day-of-week as non-wildcards expecting AND behavior (cron uses OR), and missing a space between fields causing the parser to misread the expression entirely.

Reading the parser result before editing the crontab

Do not stop at a green syntax check. Read the plain-English description and compare the next several run times with the schedule you intended. This catches logic mistakes that are technically valid, such as a weekday rule that fires more often than expected or a step expression that skips the target hour. Pay special attention to expressions that combine day-of-month with day-of-week, since the OR behavior between those two fields is the single most common source of unintended trigger frequency.

Treat the parser as a translation step, not a rubber stamp, because a green check only proves the fields parse rather than that the schedule matches your intent. The next several trigger times are the real test: skim them for the cadence, weekday, and month pattern you expected, and only then paste the expression into the crontab. This two-step habit turns a silent misconfiguration into a visible one before the job is live.

Practical syntax validation techniques

Browser parsers give instant feedback on expression structure and show the next trigger times, which makes them the fastest way to confirm an expression is well-formed before you deploy it to a live server. crontab -l on Linux lists the current crontab but does not validate syntax; it prints the file as-is.

Choosing a programmatic validator

Consequently, croniter (Python) or cron-parser (Node.js) are the best programmatic validators: both parse expressions and can enumerate the next N trigger times without running any system cron daemon. For CI pipelines that already run Node.js tests, cron-parser integrates with a single require() call and throws a descriptive error on malformed input,³ making it the fastest path from pull request to validated schedule. Python projects benefit from croniter in the same way, with croniter.is_valid() returning a boolean that fits cleanly into existing test assertions.⁴

Edge cases that pass syntax checks but behave unexpectedly

0 0 29 2 * runs on February 29 (valid, but fires only in leap years). 0 0 31 * * fires on the 31st of each month, but only 7 of 12 months have a 31st day.⁵ Building on this, 0 0 1 * 1 fires on the 1st of every month AND every Monday, not just Mondays that fall on the 1st. None of these are syntax errors, but all produce surprising schedules.

The common thread is that cron cannot express conditional logic: it can only list field values and operators. When a schedule depends on the actual calendar (month length, leap year, day-of-week interactions), the expression either over-triggers or under-triggers. The safest approach is to combine a conservative cron trigger with a script-level guard that exits early on non-matching days, rather than trying to encode every calendar rule into the expression itself.

Programmatic validation in CI and deployment pipelines

For teams that manage cron expressions in version-controlled configuration files (Kubernetes CronJob manifests, GitHub Actions workflows, or wrangler.toml), adding expression validation to the CI pipeline catches errors before they reach production. The cron-parser npm package and Python's croniter library both expose a parse function that throws on invalid input. Treating schedule validation as a test step rather than a manual review makes it impossible for a malformed expression to reach a production cluster unnoticed.

Adding a cron validation step in Node.js

In a Node.js test suite, a single assertion covers each expression: require('cron-parser').parseExpression('0 9 * * 1-5') throws if the expression is malformed.³ Wrap this in a test that iterates over every cron expression in your configuration and confirms each one parses without error. Running this check on every pull request catches field range violations, missing steps, and malformed operators before the schedule reaches a production environment.

Validating logic errors that syntax checks miss

Passing a cron expression through a syntax validator confirms the fields are well-formed, but syntax checks cannot detect logic errors. An expression like 0 0 15,31 * * is syntactically valid but fires only 10 or 11 times per year, not monthly, because not every month has a 31st day.

Diagnosing logic errors requires inspecting the next N trigger times: paste the expression in so you can count how many times your expression actually fires per year, then read the plain-English description alongside the trigger dates to confirm they match your intent. A job you expect to run 12 times per year that fires 56 times has a logic error in its day-of-week or day-of-month field. Fix the most permissive field first and re-inspect the trigger list after each change, so a logic error like this shows up before the schedule reaches production.

When to use this

Use a syntax checker whenever you write a new cron expression, when debugging a job that is not firing on time, or when reviewing another developer's crontab entry before it is deployed to production.

Examples

60 * * * *

59 * * * *

0 */0 * * *

0 */1 * * *