Cron Expression Validator

Validate cron expressions and see a detailed field-by-field breakdown

Try an example

Cron expression

minute hour day(month) month day(week)

Valid cron expression

Field breakdown

Minute*/15(0–59)

Expands to: 0, 15, 30, 45

Hour0-6(0–23)

Expands to: 0, 1, 2, 3, 4, 5, 6

Day of month1,15(1–31)

Expands to: 1, 15

Month*(1–12)

Expands to: all (1–12)

Day of week1-5(0–6)

Expands to: 1, 2, 3, 4, 5

Also try:Timestamp Converter Cron Expression Parser Cron Expression Generator

What Is Cron Expression Validation?

Cron expression validation is the process of checking whether a cron string follows the correct syntax rules before it reaches a scheduler. A cron expression uses five space-separated fields (minute, hour, day-of-month, month, day-of-week) to define a recurring schedule. If any field contains an out-of-range value, an invalid operator, or a structural error like the wrong number of fields, the expression will either be rejected by the scheduler at deploy time or silently fail to match any trigger time.

Validating a cron expression online catches errors earlier than deploying to production and waiting for a missed job. Typical mistakes include writing 25 in the hour field (valid range: 0-23), using a step of zero (*/0, which is undefined), reversing range bounds (5-1 instead of 1-5), or adding extra fields that belong to non-standard formats like Quartz. A syntax checker flags these problems instantly and tells you exactly which field is wrong.

Cron validation differs from cron parsing. A parser takes a valid expression and translates it into a human-readable schedule. A validator answers a simpler question: is this expression well-formed? Validate before you parse — there is no point feeding an invalid expression to a scheduler. In CI/CD pipelines, automated cron validation prevents broken schedules from being merged into config files.

Why Use This Cron Validator?

A cron expression has strict syntax rules, and schedulers provide inconsistent error messages when those rules are broken. Some schedulers reject the expression with a cryptic error; others accept it silently and never fire. This validator gives you a clear, field-by-field diagnosis before you deploy.

⚡

Instant Syntax Checking

Paste or type a cron expression and see whether it passes validation immediately. No form submission, no delay. The result updates as you type.

🔒

Privacy-first Processing

Validation runs entirely in your browser. Your cron expressions and schedule configurations are never sent to a server or stored anywhere.

🔍

Field-by-field Error Reporting

When an expression is invalid, the validator identifies which field caused the error and why. No guessing which of the five fields has the problem.

📋

No Account Required

Open the page and start checking. No login, no API key, no installation. Works on any device with a modern browser, including mobile.

Cron Validator Use Cases

Frontend Developer

Validate cron expressions entered by users in scheduling UIs before saving them to the database. Catch syntax errors on the client side instead of waiting for a backend rejection.

Backend Engineer

Check cron expressions in task queue configurations (Celery beat, Hangfire, Quartz) during code review. Verify that a refactored schedule string still passes syntax validation.

DevOps / SRE

Validate cron schedules in Kubernetes CronJob manifests and CI/CD pipeline configs before applying them. Prevent a typo in a backup schedule from going unnoticed until the backup is missed.

QA Engineer

Test that your application correctly rejects invalid cron input. Generate known-bad expressions (out-of-range values, wrong field count) and confirm the error handling works.

Data Engineer

Validate cron triggers for Airflow DAGs and dbt scheduled runs. Confirm that pipeline schedules parsed from YAML or JSON config files are syntactically correct before deploying.

Student / Learner

Experiment with cron syntax and get instant feedback on what is valid and what breaks. Learn the field ranges, operators, and edge cases by testing expressions and reading the error messages.

Common Cron Syntax Errors

The table below lists the most frequent cron expression errors and what causes them. These are the mistakes that crop up repeatedly in production configs and CI/CD pipelines.

Error type	Example	What went wrong
Too few fields	0 9 * *	Missing the day-of-week field. Standard cron requires exactly 5 fields.
Too many fields	0 0 9 * * 1 2026	Extra fields. Some tools add seconds or year, but standard cron uses 5.
Value out of range	0 25 * * *	Hour field accepts 0-23. Value 25 exceeds the maximum.
Invalid step base	0 0 32/2 * *	Day-of-month starts at 32, which exceeds the 1-31 range.
Step of zero	/0 * * *	Step value must be 1 or greater. Zero creates an infinite loop.
Empty field	0 9 * * 1	Double space creates an empty field. Each field needs a value.
Invalid character	0 9 * * Mon-Fry	Typo in day name. Use three-letter abbreviations: MON, TUE, WED, THU, FRI, SAT, SUN.
Reversed range	0 9 * * 5-1	Range end (1) is less than start (5). Write 1-5 or use a list: 5,6,0,1.

Valid vs. Invalid Cron Expressions

A quick reference of well-formed expressions alongside common mistakes. Use this to sanity-check your expression before pasting it into a scheduler config.

Valid expressions

* * * * *

0 9 * * 1-5

*/15 * * * *

0 0 1,15 * *

30 2 * * 0

0 */6 * * *

Invalid expressions

0 9 * *4 fields, need 5

0 25 * * *hour max is 23

*/0 * * * *step cannot be 0

0 9 * * 8day-of-week max is 6

60 * * * *minute max is 59

0 0 0 * *day-of-month min is 1

Code Examples

How to validate cron expressions programmatically in JavaScript, Python, Go, and Bash. Each example shows how to catch invalid syntax and extract a meaningful error message.

JavaScript (Node.js)

import { parseExpression } from 'cron-parser';

// Validate a cron expression by attempting to parse it
function validateCron(expr) {
  try {
    parseExpression(expr);
    return { valid: true, error: null };
  } catch (err) {
    return { valid: false, error: err.message };
  }
}

console.log(validateCron('0 9 * * 1-5'));
// → { valid: true, error: null }

console.log(validateCron('0 25 * * *'));
// → { valid: false, error: "Constraint error, got value 25 expected range 0-23" }

// Validate with field-level detail using cron-validator
import { isValidCron } from 'cron-validator';

isValidCron('*/15 * * * *');           // → true
isValidCron('*/15 * * * *', { seconds: true }); // → false (expects 6 fields)
isValidCron('0 0 31 2 *');             // → true (syntactically valid, Feb 31 never fires)

Python

from croniter import croniter

# Validate by checking if croniter can parse the expression
def validate_cron(expr: str) -> dict:
    if croniter.is_valid(expr):
        return {"valid": True, "error": None}
    # Get a more specific error message
    try:
        croniter(expr)
    except (ValueError, KeyError) as e:
        return {"valid": False, "error": str(e)}
    return {"valid": False, "error": "Unknown error"}

print(validate_cron("0 9 * * 1-5"))
# → {'valid': True, 'error': None}

print(validate_cron("0 25 * * *"))
# → {'valid': False, 'error': '...out of range...'}

print(validate_cron("* * *"))
# → {'valid': False, 'error': 'Exactly 5 or 6 columns...'}

# Field-level validation
from crontab import CronTab

cron = CronTab(tab="")
job = cron.new(command="/bin/true")
try:
    job.setall("0 9 * * 1-5")
    print(job.is_valid())  # → True
except Exception as e:
    print(f"Invalid: {e}")

package main

import (
    "fmt"
    "github.com/robfig/cron/v3"
)

// ValidateCron checks whether a 5-field cron expression is syntactically correct
func ValidateCron(expr string) (bool, error) {
    parser := cron.NewParser(
        cron.Minute | cron.Hour | cron.Dom | cron.Month | cron.Dow,
    )
    _, err := parser.Parse(expr)
    if err != nil {
        return false, err
    }
    return true, nil
}

func main() {
    exprs := []string{
        "0 9 * * 1-5",   // valid
        "0 25 * * *",    // invalid: hour 25
        "*/15 * * * *",  // valid
        "0 0 32 * *",    // invalid: day 32
    }

    for _, e := range exprs {
        ok, err := ValidateCron(e)
        if ok {
            fmt.Printf("%-20s  VALID
", e)
        } else {
            fmt.Printf("%-20s  INVALID: %v
", e, err)
        }
    }
}

Bash

#!/bin/bash

# Validate cron syntax using Python one-liner
validate_cron() {
  python3 -c "
from croniter import croniter
import sys
expr = sys.argv[1]
if croniter.is_valid(expr):
    print(f'VALID: {expr}')
    sys.exit(0)
else:
    print(f'INVALID: {expr}')
    sys.exit(1)
" "$1"
}

validate_cron "0 9 * * 1-5"     # → VALID: 0 9 * * 1-5
validate_cron "0 25 * * *"      # → INVALID: 0 25 * * *

# Quick regex pre-check (catches field count and obvious issues)
cron_regex='^([0-9*/,-]+\s+){4}[0-9*/,-]+$'
echo "*/5 * * * *" | grep -Eq "$cron_regex" && echo "passes basic check"
echo "* * *" | grep -Eq "$cron_regex" || echo "fails basic check"

Frequently Asked Questions

What makes a cron expression invalid?

A cron expression is invalid when it breaks the syntax rules of the five-field format. Common causes: wrong number of fields (fewer than 5 or more than 5 for standard cron), a value outside the allowed range (e.g., hour 25, minute 60, day-of-month 0), a step of zero (*/0), reversed range bounds (5-1), or unrecognized characters. The expression must have exactly five space-separated fields with valid values and operators in each.

Is a cron expression valid if it never fires?

Yes, syntactically. An expression like 0 0 31 2 * (February 31st) passes syntax validation because each field contains values within the allowed ranges. But it will never trigger because February never has 31 days. Most validators check syntax only, not semantic correctness. If you need to catch unreachable schedules, calculate the next N run times and check if the list is empty.

How do I validate a 6-field or 7-field cron expression?

Standard POSIX cron uses 5 fields. Quartz Scheduler adds a seconds field at the beginning (6 fields) and an optional year field at the end (7 fields). AWS EventBridge uses 6 fields. This validator checks the standard 5-field format. To validate Quartz or EventBridge expressions, use a library that supports the extended format, such as cron-parser with the extended option in Node.js or quartz-cron in Java.

Can I use named days and months in cron expressions?

Most cron implementations accept three-letter English abbreviations for months (JAN-DEC) and days of the week (SUN-SAT). These are case-insensitive in crontab but may be case-sensitive in other systems. Named values cannot be used in ranges on all platforms: MON-FRI works in crontab but not in every library. If portability matters, use numeric values (1-5 for Monday through Friday).

Why does my cron expression work in crontab but fail in Kubernetes?

Kubernetes CronJobs use the same 5-field format as crontab but are parsed by the Go cron library, which has stricter validation. Expressions that crontab tolerates (like trailing whitespace, or both day-of-month and day-of-week set to non-wildcard values) may behave differently. Kubernetes also defaults to the controller-manager timezone (usually UTC), not the node's local timezone. Always validate the expression against the specific scheduler you are deploying to.

How should I validate cron expressions in a CI/CD pipeline?

Add a validation step that runs before deployment. In a Node.js project, use cron-parser or cron-validator in a test file that reads cron strings from your config and asserts they parse without error. In Python, use croniter.is_valid(). In a shell script, call the validation function and exit with a non-zero code on failure. This catches typos and copy-paste errors before they reach production.

What is the difference between cron validation and cron linting?

Validation checks whether an expression is syntactically correct: right number of fields, values in range, valid operators. Linting goes further by checking for likely mistakes that are technically valid: schedules that never fire (Feb 31), overlapping jobs, step values that skip expected intervals (*/7 resets every hour), or schedules without timezone documentation. Validation answers 'will this parse?' Linting answers 'is this probably what you meant?'