Cron Expression Validator

Cron 표현식의 유효성을 검사하고 필드별 상세 분석 결과를 확인

예시 시도

Cron 표현식

minute hour day(month) month day(week)

유효한 Cron 표현식

필드 분석

Minute*/15(0–59)

확장 결과: 0, 15, 30, 45

Hour0-6(0–23)

확장 결과: 0, 1, 2, 3, 4, 5, 6

Day of month1,15(1–31)

확장 결과: 1, 15

Month*(1–12)

확장 결과: all (1–12)

Day of week1-5(0–6)

확장 결과: 1, 2, 3, 4, 5

Cron 표현식 유효성 검사란?

Cron 표현식 유효성 검사는 스케줄러에 전달되기 전에 Cron 문자열이 올바른 구문 규칙을 따르는지 확인하는 과정입니다. Cron 표현식은 반복 스케줄을 정의하는 5개의 공백으로 구분된 필드(분, 시, 월별 일, 월, 요일)를 사용합니다. 필드 중 하나라도 허용 범위를 벗어난 값, 잘못된 연산자, 또는 잘못된 필드 수와 같은 구조적 오류를 포함하면, 표현식은 배포 시 스케줄러에 의해 거부되거나 트리거 시간과 무관하게 조용히 실패합니다.

Cron 표현식을 온라인으로 검사하면 프로덕션에 배포하여 누락된 작업을 기다리는 것보다 오류를 더 일찍 발견할 수 있습니다. 대표적인 실수로는 시 필드에 25를 입력하는 것(유효 범위: 0-23), 스텝 값으로 0을 사용하는 것(*/0은 정의되지 않음), 범위 경계를 반전시키는 것(1-5 대신 5-1), 또는 Quartz와 같은 비표준 형식에 속하는 필드를 추가하는 것이 있습니다. 구문 검사기는 이러한 문제를 즉시 감지하고 정확히 어느 필드가 잘못되었는지 알려줍니다.

Cron 유효성 검사는 Cron 파싱과 다릅니다. 파서는 유효한 표현식을 받아 사람이 읽을 수 있는 스케줄로 변환합니다. 유효성 검사기는 더 단순한 질문에 답합니다: 이 표현식이 올바른 형식인가? 파싱 전에 검사하세요 — 유효하지 않은 표현식을 스케줄러에 전달하는 것은 의미가 없습니다. CI/CD 파이프라인에서 자동화된 Cron 유효성 검사는 잘못된 스케줄이 설정 파일에 병합되는 것을 방지합니다.

이 Cron 유효성 검사기를 사용하는 이유

Cron 표현식은 엄격한 구문 규칙을 가지며, 스케줄러는 규칙이 위반될 때 일관성 없는 오류 메시지를 제공합니다. 어떤 스케줄러는 알 수 없는 오류와 함께 표현식을 거부하고, 다른 것들은 조용히 수락한 후 실행하지 않습니다. 이 유효성 검사기는 배포 전에 명확한 필드별 진단을 제공합니다.

즉시 구문 검사
Cron 표현식을 붙여넣거나 입력하면 즉시 유효성 검사 결과를 확인할 수 있습니다. 폼 제출이나 대기 시간 없이 입력하는 동안 결과가 업데이트됩니다.
🔒
개인정보 보호 우선 처리
유효성 검사는 전적으로 브라우저에서 실행됩니다. Cron 표현식과 스케줄 설정은 서버로 전송되거나 어디에도 저장되지 않습니다.
🔍
필드별 오류 보고
표현식이 유효하지 않을 때 유효성 검사기는 어느 필드가 오류를 일으켰는지와 그 이유를 식별합니다. 5개 필드 중 어느 것이 문제인지 추측할 필요가 없습니다.
📋
계정 불필요
페이지를 열고 바로 검사를 시작하세요. 로그인, API 키, 설치가 필요 없습니다. 모바일을 포함한 최신 브라우저가 있는 모든 기기에서 작동합니다.

Cron 유효성 검사기 활용 사례

프론트엔드 개발자
스케줄링 UI에서 사용자가 입력한 Cron 표현식을 데이터베이스에 저장하기 전에 유효성을 검사합니다. 백엔드 거부를 기다리는 대신 클라이언트 측에서 구문 오류를 잡으세요.
백엔드 엔지니어
코드 리뷰 중 작업 큐 설정(Celery beat, Hangfire, Quartz)의 Cron 표현식을 확인합니다. 리팩토링된 스케줄 문자열이 여전히 구문 유효성 검사를 통과하는지 검증하세요.
DevOps / SRE
Kubernetes CronJob 매니페스트와 CI/CD 파이프라인 설정의 Cron 스케줄을 적용 전에 유효성을 검사합니다. 백업 스케줄의 오타가 백업이 누락될 때까지 발견되지 않는 상황을 방지하세요.
QA 엔지니어
애플리케이션이 유효하지 않은 Cron 입력을 올바르게 거부하는지 테스트합니다. 알려진 잘못된 표현식(범위 초과 값, 잘못된 필드 수)을 생성하고 오류 처리가 작동하는지 확인하세요.
데이터 엔지니어
Airflow DAG와 dbt 예약 실행의 Cron 트리거 유효성을 검사합니다. YAML 또는 JSON 설정 파일에서 파싱한 파이프라인 스케줄이 배포 전에 구문적으로 올바른지 확인하세요.
학생 / 학습자
Cron 구문을 실험하며 유효한 것과 오류가 나는 것에 대한 즉각적인 피드백을 받으세요. 표현식을 테스트하고 오류 메시지를 읽으면서 필드 범위, 연산자, 엣지 케이스를 학습하세요.

자주 발생하는 Cron 구문 오류

아래 표는 가장 빈번하게 발생하는 Cron 표현식 오류와 그 원인을 나열합니다. 이것들은 프로덕션 설정과 CI/CD 파이프라인에서 반복적으로 나타나는 실수입니다.

오류 유형예시문제점
Too few fields0 9 * *Missing the day-of-week field. Standard cron requires exactly 5 fields.
Too many fields0 0 9 * * 1 2026Extra fields. Some tools add seconds or year, but standard cron uses 5.
Value out of range0 25 * * *Hour field accepts 0-23. Value 25 exceeds the maximum.
Invalid step base0 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 field0 9 * * 1Double space creates an empty field. Each field needs a value.
Invalid character0 9 * * Mon-FryTypo in day name. Use three-letter abbreviations: MON, TUE, WED, THU, FRI, SAT, SUN.
Reversed range0 9 * * 5-1Range end (1) is less than start (5). Write 1-5 or use a list: 5,6,0,1.

유효한 Cron 표현식 vs. 유효하지 않은 표현식

올바른 형식의 표현식과 자주 발생하는 실수를 빠르게 비교합니다. 스케줄러 설정에 붙여넣기 전에 표현식을 확인하는 데 활용하세요.

유효한 표현식
* * * * *
0 9 * * 1-5
*/15 * * * *
0 0 1,15 * *
30 2 * * 0
0 */6 * * *
유효하지 않은 표현식
0 9 * *필드 4개, 5개 필요
0 25 * * *시 최대값은 23
*/0 * * * *스텝은 0이 될 수 없음
0 9 * * 8요일 최대값은 6
60 * * * *분 최대값은 59
0 0 0 * *월별 일 최소값은 1

코드 예제

JavaScript, Python, Go, Bash에서 Cron 표현식의 유효성을 프로그래밍 방식으로 검사하는 방법. 각 예제는 유효하지 않은 구문을 잡고 의미 있는 오류 메시지를 추출하는 방법을 보여줍니다.

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}")
Go
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"

자주 묻는 질문

Cron 표현식이 유효하지 않은 경우는 어떤 경우인가요?
Cron 표현식은 5개 필드 형식의 구문 규칙을 위반할 때 유효하지 않습니다. 일반적인 원인으로는 잘못된 필드 수(표준 Cron의 경우 5개 미만 또는 초과), 허용 범위를 벗어난 값(예: 시 25, 분 60, 월별 일 0), 스텝 값 0(*/0), 반전된 범위 경계(5-1), 또는 인식할 수 없는 문자가 있습니다. 표현식은 유효한 값과 연산자를 포함하는 정확히 5개의 공백으로 구분된 필드를 가져야 합니다.
한 번도 실행되지 않는 Cron 표현식도 유효한가요?
구문적으로는 그렇습니다. 0 0 31 2 *(2월 31일)과 같은 표현식은 각 필드가 허용 범위 내의 값을 포함하므로 구문 유효성 검사를 통과합니다. 하지만 2월에는 31일이 없으므로 절대 실행되지 않습니다. 대부분의 유효성 검사기는 의미적 정확성이 아닌 구문만 확인합니다. 도달할 수 없는 스케줄을 잡아야 한다면 다음 N번의 실행 시간을 계산하여 목록이 비어 있는지 확인하세요.
6개 또는 7개 필드 Cron 표현식의 유효성은 어떻게 검사하나요?
표준 POSIX Cron은 5개 필드를 사용합니다. Quartz Scheduler는 처음에 초 필드를 추가하고(6개 필드) 끝에 선택적 연도 필드를 추가합니다(7개 필드). AWS EventBridge는 6개 필드를 사용합니다. 이 유효성 검사기는 표준 5개 필드 형식을 확인합니다. Quartz 또는 EventBridge 표현식의 유효성을 검사하려면 Node.js의 extended 옵션이 있는 cron-parser나 Java의 quartz-cron과 같이 확장 형식을 지원하는 라이브러리를 사용하세요.
Cron 표현식에서 요일 및 월 이름을 사용할 수 있나요?
대부분의 Cron 구현은 월(JAN-DEC)과 요일(SUN-SAT)에 대한 세 글자 영어 약어를 허용합니다. crontab에서는 대소문자를 구분하지 않지만 다른 시스템에서는 구분할 수 있습니다. 모든 플랫폼에서 이름 값을 범위에 사용할 수 있는 것은 아닙니다. MON-FRI는 crontab에서 작동하지만 모든 라이브러리에서 그렇지는 않습니다. 이식성이 중요하다면 숫자 값을 사용하세요(월요일부터 금요일까지는 1-5).
crontab에서는 작동하던 Cron 표현식이 Kubernetes에서 실패하는 이유는?
Kubernetes CronJob은 crontab과 동일한 5개 필드 형식을 사용하지만 더 엄격한 유효성 검사를 가진 Go Cron 라이브러리로 파싱됩니다. crontab이 허용하는 표현식(후행 공백이나 월별 일과 요일 모두 비와일드카드 값으로 설정)은 다르게 동작할 수 있습니다. 또한 Kubernetes는 노드의 로컬 타임존이 아닌 controller-manager 타임존(보통 UTC)을 기본값으로 사용합니다. 항상 배포하려는 특정 스케줄러에 맞게 표현식의 유효성을 검사하세요.
CI/CD 파이프라인에서 Cron 표현식의 유효성을 어떻게 검사해야 하나요?
배포 전에 실행되는 유효성 검사 단계를 추가하세요. Node.js 프로젝트에서는 설정에서 Cron 문자열을 읽고 오류 없이 파싱되는지 확인하는 테스트 파일에서 cron-parser 또는 cron-validator를 사용하세요. Python에서는 croniter.is_valid()를 사용하세요. 셸 스크립트에서는 유효성 검사 함수를 호출하고 실패 시 0이 아닌 코드로 종료하세요. 이렇게 하면 오타와 복사-붙여넣기 오류가 프로덕션에 도달하기 전에 잡힙니다.
Cron 유효성 검사와 Cron 린팅의 차이는 무엇인가요?
유효성 검사는 표현식이 구문적으로 올바른지 확인합니다: 올바른 필드 수, 범위 내 값, 유효한 연산자. 린팅은 기술적으로 유효하지만 실수일 가능성이 있는 것들을 추가로 확인합니다: 절대 실행되지 않는 스케줄(2월 31일), 겹치는 작업, 예상 간격을 건너뛰는 스텝 값(*/7은 매시간 재설정), 또는 타임존 문서화 없는 스케줄. 유효성 검사는 '파싱될까?'에 답하고, 린팅은 '의도한 것이 맞는가?'에 답합니다.