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は未定義)、範囲の上下を逆にする(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式と無効なCron式

正しい形式の式とよくある間違いのクイックリファレンスです。スケジューラ設定に貼り付ける前に、式の確認にご活用ください。

有効な式
* * * * *
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未満または5超)、許容範囲外の値(時が25、分が60、日が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)に英語の3文字略称が使えます。crontabでは大文字・小文字を区別しませんが、他のシステムでは区別する場合があります。名前付きの値はすべてのプラットフォームで範囲指定に使えるわけではありません。MON-FRIはcrontabでは動作しますが、すべてのライブラリで対応しているわけではありません。移植性が重要な場合は数値(月曜から金曜は1-5)を使用してください。
crontabで動作するCron式がKubernetesで失敗するのはなぜですか?
Kubernetes CronJobはcrontabと同じ5フィールド形式を使用しますが、より厳密な検証を行うGoのcronライブラリで解析されます。crontabが許容する式(末尾の空白、day-of-monthとday-of-weekの両方にワイルドカード以外の値を指定するなど)は動作が異なる場合があります。Kubernetesはデフォルトでノードのローカルタイムゾーンではなく、kube-controller-managerのタイムゾーン(通常はUTC)を使用します。デプロイ先の特定のスケジューラに対して式を検証するようにしてください。
CI/CDパイプラインでCron式を検証するにはどうすればよいですか?
デプロイ前に実行される検証ステップを追加してください。Node.jsプロジェクトでは、設定からcron文字列を読み込んでエラーなしに解析できることをアサートするテストファイルにcron-parserまたはcron-validatorを使用します。Pythonではcroniter.is_valid()を使用します。シェルスクリプトでは、検証関数を呼び出して失敗時にゼロ以外のコードで終了します。これにより、タイポやコピーペーストのミスが本番環境に到達する前に検出できます。
Cron式の検証とCron式のリンティングの違いは何ですか?
検証は式が構文的に正しいかどうかを確認します:フィールド数が正しいか、値が範囲内か、演算子が有効か。リンティングはさらに踏み込み、技術的には有効でも問題が起きそうな点を確認します:一度も実行されないスケジュール(2月31日)、重複するジョブ、想定した間隔をスキップするステップ値(*/7は毎時リセット)、タイムゾーンの記載がないスケジュールなどです。検証は「これは解析できるか?」に答え、リンティングは「これはおそらく意図した通りか?」に答えます。