クロン式の説明

仕組み

1. cron式を入力: 0 9 * * 1-5のような5フィールドまたは6フィールドのcron文字列を貼り付けます。
2. 平易な言葉での説明を読む: ツールはタスクが実行されるタイミングの読みやすい説明をすぐに表示します。
3. 次の実行を表示: 現在の日付と時刻から次の5〜10回の予定実行のリストが表示されます。
4. 検証: 無効な式は、問題を説明する正確なエラーメッセージで強調表示されます。

1 分間ティックの半世紀

cron は世界中のほとんどのサーバーで継続的かつ毎日使用されている最も古いスケジューラです。歴史的記録での最初の出現は1975年5月にさかのぼります、AT&T Bell Laboratories が Research Unix ブランチの一部として初期バージョンを出荷しました。名前はギリシャの時間の擬人化 Chronos へのうなずきで、設計は奇妙な優雅さで老化しました:1970 年代中盤に Bell Labs エンジニアが /usr/lib/crontab にタイプしたのと同じ 5 つのスペース区切りフィールドが、Kubernetes CronJob、GitHub Actions スケジュール、現在フランクフルトのどこかの仮想プライベートサーバーでの夜間データベースバックアップを依然として駆動しています。1975 年の実装は最小限でした、root が所有する単一の crontab がマシン全体にサービスを提供しました。ユーザーが繰り返しタスクを望んだ場合、彼らは管理者に手で行を追加するように依頼しました。cron は1979 年にリリースされた Version 7 Unixでより広い世界に渡りました。Purdue 大学の Robert Brown と Keith Williamson は1979年後半に cron を拡張して複数ユーザーを処理し、ユーザーごとの crontab -e フローを導入しました。決定的な書き換えは Paul Vixie が1987年5月6日に vixie-cron 1.0 をリリースしたときに来ました、vixie-cron は特殊文字を正式化し、@reboot、@hourly、@daily、@weekly、@monthly、@yearly ショートカットを導入しました。Vixie 3.0(1993年12月27日)はステップ値(/)を追加し、軽微な修正と一緒に当時のほぼすべての Linux ディストリビューションと BSD に統合されました。POSIX は1992年(IEEE Std 1003.2-1992)に追いつきました。現代の cron のすべての奇癖、日曜日のオフセット番号付け、フィールド合併 vs 交差バグ、はその進化の傷跡です、何も一度に設計されませんでした。

5 フィールド式の解剖

標準 cron 式は 5 つのスペース区切りフィールドで構成されます。左から右へ、それらは尋ねます:どの分の、どの時間の、どの月の日の、どの月の、どの曜日の? 正確な範囲は POSIX cron で交渉不可能です:分 0-59、時 0-23、月の日 1-31、月 1-12、曜日 0-7、0 と 7 の両方が日曜日を表します。各フィールドは自由に構成される 5 つの演算子を受け入れます:* はあらゆる有効値を意味、, は離散値のリストを区切ります(0,15,30,45 * * * * は時の上、15 分、30 分、45 分に各時間実行)、- は包含的範囲です(時フィールドの 9-17 は 9、10、11、12、13、14、15、16、17 を意味)、/ はステップ値です(分フィールドの */15 はゼロから始めて 15 分ごとを意味、つまり 0、15、30、45)。月と曜日も 3 文字の省略形で書けます:JAN-DEC と SUN-SAT。詳細な例:*/15 9-17 * * 1-5 は毎月の毎日、毎年の毎月、月曜日から金曜日、9 時から 17 時の包含的時間中、15 分ごと、「平日の営業時間中、四半期ごと」と読みます。

月の日 / 曜日の罠

最も影響の大きい cron 奇癖、35 年間にわたって本番でサイトの停止、欠落したバックアップ、静かに間違った請求サイクルを引き起こしたもの、は両方が制限されているとき cron が月の日と曜日フィールドを組み合わせる方法です。POSIX 表現はここで異常に正確です:「'月の日'(フィールド 3)と '曜日'(フィールド 5)の両方が制限されている("*" を含まない)場合、いずれかまたは両方が現在の日に一致しなければならない」。言い換えれば、どちらのフィールドもワイルドカードでないとき、cron は 2 つの合併を取ります、タスクはどちらかの制限を満たすあらゆる日に実行されます。これはほとんどのユーザーが仮定するものの反対です。0 0 13 * 5 を声に出して読む、「13 日の真夜中、金曜日に」、は交差として自然に聞こえます:13 日の金曜日のみ。vixie-cron とその子孫では、それは実際には「毎月の毎 13 日と毎金曜日」を意味、月に約 9 回実行します。さらに悪いことに、vixie-cron は各日フィールドの最初の文字のみを検査することで合併または交差を使用するかどうかを決定します。Paul Vixie 自身は動作をバグとして認めましたが、修正することを拒否しました、それを修正することは最小驚きの原則に違反すると指摘して、何百万もの crontab がすでに既存の動作が意図的であると仮定して書かれていました。バグは今や機能、不滅で自己伝播。実用的なメンタルモデル:月の日と曜日の両方を制限しているのに気付き、本当に交差(例えば「毎月の第 2 火曜日」)を望むなら、それをサポートする実装(Quartz、拡張付き cronie)で # 演算子を使用してください:0 12 ? * 2#2。純粋な POSIX cron では、交差は単一の式で表現することが本当に不可能で、cron が呼び出すスクリプト内でフィルタリングする必要があります。

ショートカットマクロ

• @yearly / @annually = 0 0 1 1 *、1 月 1 日の真夜中
• @monthly = 0 0 1 * *、毎月 1 日の真夜中
• @weekly = 0 0 * * 0、日曜日の真夜中
• @daily / @midnight = 0 0 * * *、毎日真夜中
• @hourly = 0 * * * *、毎時の上に
• @reboot、特殊:cron デーモンが起動するときに 1 回トリガー(システム再起動ごとに 1 回ではない、cron が停止して再起動できるシステムでは、@reboot が再びトリガー)

これらのショートカットは POSIX の一部ではありません。厳密に POSIX 環境は @daily を拒否します、実際には、読者が遭遇する可能性のあるあらゆる cron 実装(vixie-cron、cronie、fcron、ISC cron、コンテナイメージ)はそれらをサポートします。

方言、標準 vs Quartz vs AWS vs K8s vs systemd

「cron 式」は今や互いに互換性のない方言の小さなファミリーです。標準 5 フィールド cron(POSIX、vixie-cron、cronie): 分 時 月の日 月 曜日、普遍的な最小公分母。Quartz Scheduler(6 または 7 フィールド、Java エコシステム): 秒 分 時 月の日 月 曜日 [年]、?、L(last)、W(weekday)、#(月の n 番目曜日)を導入。Spring と Spring Boot の @Scheduled は Quartz を使用。Kubernetes CronJob は標準 5 フィールド cron を使用、別個の spec.timeZone フィールドで K8s 1.27 で GA に進みました(CronJob リソース自体は2021年4月の 1.21 で GA になりました)、タイムゾーン形式は IANA tz データベース(Europe/Berlin、America/New_York)。GitHub Actions の cron スケジュールは POSIX 5 フィールド cron を使用し UTC で実行。AWS EventBridge の cron は 6 フィールド(分 時 月の日 月 曜日 年)を使用、月の日または曜日に ? 演算子を要求(両方を制限することはできません)、SUN=1 で 1-7 を使用、つまり EventBridge 式 0 12 ? * 2 * は火曜日ではなく月曜日の正午に実行します。systemd タイマーは完全に異なる構文(OnCalendar=*-*-* 02:00:00)を使用し、システムスケジューリングのために現代の Linux で cron を徐々に置き換えています、両方ともすべての主要ディストリビューションで並んで出荷されています。Cloud Scheduler(Google Cloud)は明示的なタイムゾーン設定で標準 5 フィールド cron を使用。プラットフォーム間で式を翻訳するには注意深い注意が必要です:コピー貼り付けされた EventBridge スケジュールは日番号付けのオフセットのために vixie-cron で間違った曜日に実行します。

覚えるべき一般的なパターン

• */15 * * * *、15 分ごと(各時間の 00:00、00:15、00:30、00:45)
• */15 9-17 * * 1-5、営業時間中、平日のみ 15 分ごと
• 0 9 * * 1-5、毎平日午前 9 時
• 0 6,18 * * *、1 日 2 回、午前 6 時と午後 6 時(範囲ではなくリスト経由)
• 0 0 1 * *、毎月 1 日の真夜中
• 0 0 L * *、毎月最終日の真夜中(L は Quartz/cronie 拡張)
• 0 3 1-7 * 1、毎月の最初の月曜日午前 3 時(意図的に合併バグを使用:1-7 日と月曜日のマッチング、しかし両方の制限を満たす特定の月の唯一の日は最初の月曜日)
• 0 0 1 1,4,7,10 *、毎カレンダー四半期の最初の日の真夜中
• 0 0 * * 0,6、週末の真夜中

一般的な落とし穴

タイムゾーン。 cron はデフォルトでシステムローカル時間を使用、UTC がデフォルトのクラウドマシンで驚き。UTC サーバーの 9 AM cron タスクはニューヨーク時間の 4 AM にトリガーします。現代のスケジューラ(Kubernetes 1.27+、AWS EventBridge、Cloud Scheduler)は明示的なタイムゾーンフィールドを追加しました、クラシック cron はそうではありません。「*/N は 0 から始まる」ルール。 */15 は 0、15、30、45 を与えます、5、20、35、50 ではありません。非ゼロオフセットで開始するには、列挙(5,20,35,50)するか Quartz のみ構文 5/15 を使用する必要があります。60 分スタッキング罠。 スケジュール間隔より長く実行されるタスクはスタックする可能性、15 分ごとに開始される 3 つの 30 分バックアップは重なります。標準的な対策は flock(1) です:* * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/myjob は一度に 1 つのインスタンスのみが実行されることを保証、-n フラグはロック取得を非ブロッキングにし、後続の呼び出しはキューに入る代わりに静かに終了します。夏時間異常。 02:30 にスケジュールされた cron タスクは時計が後退する日に 2 回トリガーし、進む日にはまったくトリガーしません。cron は「DST 認識壁時計時間」の概念を持ちません、スケジュールが DST 移行を避ける必要がある場合は、影響を受けない時間(ほとんどのゾーンで 3 AM 以降)にアンカーするか、タイムゾーンセマンティクスを理解するスケジューラを使用してください。PATH ストリッピング。 cron タスクは最小限の PATH(/usr/bin:/bin)とほぼ空の環境で実行、インタラクティブシェルで動作するスクリプトは cron で失敗するかもしれません、node、python3、aws が継承された PATH にないからです。crontab の上部に PATH= を設定するか、cron コマンドで絶対パスを使用してください。メールオーバーフロー。 デフォルトで、cron は各タスクの出力をユーザーのローカルメールボックスに送信、メール設定がないサーバーで、これはディスクが満杯になるまで /var/spool/mail を静かに埋めます。出力をリダイレクト(>/dev/null 2>&1)するか、crontab の上部に MAILTO="" を設定するか、実際にメール転送を設定してください。

現代の代替、別のものを目指すとき

cron は単一マシン上のシンプルな繰り返しタスクに優れています。それは:分散スケジューリング(同じタスクがマシンごとに 1 回ではなくフリート全体で 1 回トリガー)、イベント駆動トリガー(時計ではなくメッセージキューがメッセージを受信したときに実行)、監視(タスクがメール転送を設定しない限り非ゼロコードで終了する場合 cron は静かに失敗)、リトライ(組み込みメカニズムなし、失敗したタスクは次のサイクルで再実行され状態を蓄積)、依存関係(タスク A が成功した後にのみタスク B を実行)、で悪いです。それらのケースには、現代の答えは:Kubernetes CronJob(リトライおよび並列性ポリシーを持つクラスター指向スケジューリング)、AWS EventBridge + Lambda または Step Functions(組み込み観測可能性を持つイベント駆動)、Apache Airflow または Prefect(明示的な依存関係を持つ DAG ワークフローオーケストレーション)、Temporal(耐久性のあるワークフロー実行)、healthchecks.io(cron タスクが時間通りに実行されないときに通知する「デッドマンスイッチ」)、のいずれかです。2026 年に単一マシンの繰り返しタスクには、シンプルな cron が依然として正しい答えのままです、他のすべてには、代替の 1 つが追加設定の価値があります。

よくある質問

cron 式の * は何を意味しますか?

cron フィールドのアスタリスク(*)は「あらゆる有効値」を意味、毎分、毎時、毎日、毎月、毎曜日。* * * * * は毎日毎分実行します。アスタリスクは合併 vs 交差罠のために月の日と曜日フィールドでも特別です:いずれかの日フィールドが先頭の * を持つとき、vixie-cron は交差モードを使用、どちらも持たないとき、合併モードを使用し 2 つの制限の合併で実行します。

cron タスクを 15 分ごとに実行するには?

ステップ表記を使用:*/15 * * * * は 15 分ごとに実行、xx:00、xx:15、xx:30、xx:45 で。*/N は常に 0 から始まることに注意、「分 5 から始めて 15 分ごと」のために */15 を使用することはできません、それには 5,20,35,50 * * * * を書きます。Quartz 方言 cron は 5/15 を非標準代替としてサポート。

cron と at の違いは何ですか?

cron は繰り返しスケジュールでタスクを実行(毎分、毎日、毎週)。at コマンドは特定の将来の時間に実行する単一タスクをスケジュール、at 14:30 tomorrow はそのインスタント用にタスクをキューに入れます。繰り返しタスクには cron、単一の将来実行には at を使用してください。両方とも同じ Bell Labs / vixie-cron の血統に降下し、ほとんどのシステムで同じデーモンに統合されることになりました。

なぜ私の cron タスクは私が望んだものに一致しないのか?

頻度のおおよその順序で 5 つの最も頻繁な原因:(1) 月の日 vs 曜日の混乱、cron は両方が制限されているとき、交差ではなく 2 つの合併を使用。(2) タイムゾーン、cron はデフォルトでサーバーローカル時間を使用、クラウドマシンではしばしば UTC。(3) PATH 問題、インタラクティブシェルの PATH は継承されません、コマンドラインで動作するコマンドは cron で失敗するかもしれません。(4) */N が常に 0 から始まる罠。(5) 出力がどこにもキャプチャされない、メールが設定されておらずログファイルに出力をリダイレクトしていない場合、失敗したタスクは静かに消えます。このツールの「次の 10 のスケジュールされた実行」パネルは、デプロイ前にあなたの式が実際に何を意味するかを検証する最も経済的な方法です。

このツールは非標準 cron フォーマットをサポートしますか?

それは標準 5 フィールド POSIX/vixie-cron、秒付き 6 フィールド Quartz/Spring バリアント、特殊文字列 @hourly、@daily、@weekly、@monthly、@yearly、@reboot を処理します。それは完全な Quartz 拡張(L、W、#)や AWS EventBridge の 1 ベース日番号付けを処理しません、それらにはデプロイ前にプラットフォームのバリデーターを使用してください。

私の cron 式はどこかに送信されますか?

いいえ。解析と説明は JavaScript を介してブラウザで完全に実行されます。貼り付けた式はネットワークを横断しません、Explain をクリックする間に DevTools の Network タブを確認してください。本番 CI 設定の cron 式、インフラストラクチャコード、運用ランブック、スケジュール自体が機微である可能性のあるもの(例えばメンテナンスウィンドウを示す夜間データベースエクスポートスケジュール)に安全です。

関連ツール