Crontab ジェネレーター & cron 式ビルダー

cron 式とは？

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

主な特長

cron バリアントとスケジューラ

cron 式の例

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

cron 式の組み立て方

1. 1

   cron 式を入力または貼り付け

   上部の入力欄に 5 フィールドの cron 式を入力します（例: `*/15 * * * *`）。入力に応じてツールがパースと検証を行います — 有効なら緑のチェック、無効ならフィールド名付きの赤いエラーが表示されます。`@daily` や `@hourly` などのマクロも受け付けます。

2. 2

   または 5 つのフィールド入力を調整

   フィールドの順序を覚える必要はありません — ラベル付きの入力欄で Minute、Hour、Day-of-month、Month、Day-of-week を個別に編集できます。上部の完全な式は自動的に更新されます。ワイルドカードには `*`、ステップには `*/N`、範囲には `a-b`、リストには `1,3,5` を使いましょう。

3. 3

   プリセットで一気に土台作成

   任意のプリセットチップ（15 分ごと、平日 9:00 など）をタップして一般的なスケジュールを読み込み、フィールドを微調整して要件に合わせます。本番で実際に使うパターンを 11 種類のプリセットがカバーします。

4. 4

   次回実行プレビューで確認

   今後 5 回の実行日時を確認しましょう — Local と UTC を切り替えてスケジュールが意図通りに発火するか確かめます。これが POSIX の日 / 曜日 OR の罠を本番で噛まれる前に見抜く、最も確実な方法です。

5. 5

   コピーしてスケジューラに貼り付け

   Copy をクリックして式を取得します。crontab、systemd timer、GitHub Actions の `cron:`、AWS EventBridge、Kubernetes CronJob の `schedule`、その他 cron 互換スケジューラに貼り付けましょう。対象スケジューラのタイムゾーン確認も忘れずに — 詳しくは下の Best Practices セクションを参照してください。

cron でよくあるミス

# 意図: 「毎月の第 1 金曜日」
0 0 1-7 * 5
# 実際: 毎月 1〜7 日 OR 毎週金曜日に発火 — 両方の条件

# 本物の AND セマンティクスはラッパーで
0 0 * * 5  [ $(date +\%d) -le 7 ] && /your-script
# あるいは片方の条件を捨てて緩いスケジュールを許容する

# US East の開発者が書いて UTC サーバーにデプロイ
0 9 * * *  /your-report.sh
# UTC 9:00 = US East 4:00 に発火 — 開発者の意図とは違う

# タイムゾーンを固定するか、UTC で明示的に記述
CRON_TZ=America/New_York
0 9 * * *  /your-report.sh

# 意図: 15 分ごと
15 * * * *
# 実際: 毎時 1 回、分 15 のみ（意図より 4 回/時 少ない）

# 正解
*/15 * * * *
# 15 分ごと: 毎時の分 0、15、30、45

# Linux crontab にコピーされた Quartz の 6 フィールド
0 0 9 * * 1-5
# Linux の解釈: 分=0、時=0、日=9、月=*、曜日=1-5
# = 平日にマッチする月の 9 日 0:00 — カオス

# POSIX 5 フィールド、秒を落とす
0 9 * * 1-5
# = 平日 9:00

# 2 月 30 日や 31 日 — 永遠に動かない
0 0 30 2 *
0 0 31 2 *
# パースは通るがスケジュールは発火しない

# 「2 月の最後の平日」パターンはスクリプトで
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /your-script

# Quartz: 「月の最後の金曜日」 — POSIX では無効
0 0 ? * 6L *

# POSIX で「最後の金曜日」はラッパースクリプト方式
0 0 25-31 * 5  /your-script
# 任意の月の 25〜31 日の金曜日に実行

代表的なユースケース

Linux crontab ジョブ

`/etc/crontab`、`/etc/cron.d/*`、ユーザー個別の `crontab -e` ファイル用エントリを構築・検証できます。保存前に次回実行プレビューで、サーバー設定のタイムゾーンにおける正しい時刻にスケジュールが収まることを確認しましょう。

Kubernetes CronJob のスケジュール

Kubernetes CronJob の `spec.schedule` フィールドを生成します。Kubernetes 1.27 以降は `spec.timeZone` もサポート — UTC 切り替えで UTC ベースにスケジュールを設計し、`timeZone` を明示的に設定してワーカーノードのローカル時間に左右されないようにしましょう。

GitHub Actions のスケジュールワークフロー

`on.schedule` 配下の `cron:` エントリを構築します。GitHub Actions は常に UTC で動作 — プレビューを UTC に切り替えてスケジュールを確認しましょう。15 分未満の間隔は避けてください。GitHub のスケジューラは負荷時に短間隔ジョブをスキップします。

AWS EventBridge のルール

EventBridge のスケジュールルール向けに cron 式を構成します。注意点: AWS は曜日に `?` を使う Quartz スタイルの 6 フィールド構文を採用 — 本ツールが出力する POSIX 5 フィールドに対し、先頭に秒（`0`）を付け、2 つの日フィールドのいずれかの `*` を `?` に置き換えて変換する必要があります。

GitLab CI のスケジュールパイプライン

GitLab のスケジュール CI パイプライン用の cron 式を検証できます。GitLab は本ツールが出力するのと同じ POSIX 5 フィールド構文と UI 日付ピッカーを使いますが、cron 形式の方が非標準な間隔を細かく制御できます。

Cloudflare Workers の Cron Triggers

`wrangler.toml` 内の `[triggers.crons]` エントリを構築します。Cloudflare は POSIX 5 フィールド構文を採用。最小間隔は 1 分、ワーカーは UTC で実行されます。プレビューで想定時間内にトリガーが発火することを確認しましょう。

Node.js node-cron のスケジュール

`node-cron` ライブラリ向けに式を構築します。5 フィールド POSIX と先頭の任意秒フィールドの両方に対応しています。1 分未満の精度が特に必要でなければ 5 フィールドにとどめましょう — 6 フィールド式は Linux crontab に移植できません。

コードレビューとドキュメント

PR や Runbook の cron 式を貼り付けるだけで意味が即座に分かります — `30 7 * * 1-5` の解釈に頭を悩ませたり、リファレンスカードを取り出したりする必要はもうありません。自然言語による説明はインラインコメントや README にも最適です。

cron 構文リファレンス

フィールド順: M H D M W

分（0-59）、時（0-23）、日（1-31）、月（1-12）、曜日（0-6、7 も日曜日）。語呂合わせ: 「My Hat Doesn't Match Wendy's」。曜日フィールドは数値（0-6）と名前（SUN-SAT、大文字小文字を区別しない）の両方を受け付けます。

演算子

`*` = 任意の値、`,` = リスト区切り（`1,3,5`）、`-` = 範囲（`1-5`）、`/` = ステップ（`*/15`、`5/10`）、名前: 月の JAN-DEC、曜日の SUN-SAT（大文字小文字を区別しない）。

マクロ（エイリアス）

`@yearly` = `0 0 1 1 *`、`@annually` = `0 0 1 1 *`、`@monthly` = `0 0 1 * *`、`@weekly` = `0 0 * * 0`、`@daily` = `0 0 * * *`、`@midnight` = `0 0 * * *`、`@hourly` = `0 * * * *`。`@reboot` は特殊な非スケジュール（起動時のみ実行）であり、本ツールでは説明付きのエラーで拒否されます。

POSIX 日のセマンティクス（OR ルール）

日と曜日の両方が制限されている場合（いずれも `*` でない場合）、どちらか一方にマッチすればスケジュールが実行されます — OR セマンティクスです。片方だけが制限されている場合は、そのフィールドが決定権を持ちます。両方とも `*` の場合はすべての日にマッチします。この OR ルールは vixie cron、BSD cron、大半の POSIX 実装に適用されます。Quartz は AND と OR を区別するために `?` を使います。

6 フィールドモード（Quartz-Lite）

入力に 6 つの空白区切りトークンがある場合、ツールは最初を秒フィールド（0-59）として扱います。Quartz、Spring `@Scheduled(cron=...)`、node-cron で便利です。Linux crontab や POSIX スケジューラには移植できません — それらは秒を分として扱い、すべてを 1 つずつズラして解釈します。

ステップ演算子のアンカリング

`*/N` はフィールドの最小値にアンカリングされます: 分の `*/15` は `0,15,30,45` であり、「今から 15 ごと」ではありません。非ワイルドカードのベースを使う場合: 分の `5/15` は `5,20,35,50`。フィールド範囲を割り切れないステップ値は折り返し付近でスキップしますが、これはバグではなく正しい挙動です。

バリデーション境界

分 ∈ [0,59]、時 ∈ [0,23]、日 ∈ [1,31]、月 ∈ [1,12]、曜日 ∈ [0,7]。範囲外の値はフィールド単位のエラーになります。日は月との整合性は検証されません（`0 0 31 2 *` はパースが通るものの、2 月には 31 日がないため決して発火しません — 次回実行プレビューは「今後 4 年間に実行予定はありません」と表示します）。

Quartz 演算子は拒否

POSIX cron は Quartz の `?`（特定値なし）、`L`（last）、`W`（最も近い平日）、`#`（n 番目の曜日）をサポートしていません。本ツールは無効な POSIX としてサイレントにパースするのではなく、「Quartz operators not supported」と明確にメッセージで拒否します。Quartz スケジュールには Quartz 対応ツールか Spring スケジューラを使ってください。

次回実行検索の年上限

次回実行の計算は最大 4 年先まで検索します。それより低頻度（例: 「2 月 29 日」パターン）の式は「今後 4 年間に実行予定はありません」と表示されます。不可能なパターンでの無限ループを避けるため意図的な仕様です。

cron スケジュールのベストプラクティス

サーバーは UTC で運用し、表示時にローカルへ変換

サーバーを UTC に設定し（`/etc/timezone` または `TZ=UTC`）、cron 式もすべて UTC で記述しましょう。ダッシュボードやレポートで表示するときだけローカル時間に変換します。これにより、夏時間切り替え時にローカル時間のスケジュールが二重発火・スキップするような、典型的なタイムゾーンバグを一掃できます。本ツールの UTC 切り替えを使い、最初から UTC でスケジュールを設計しましょう。

POSIX の日 / 曜日 OR の罠を避ける

OR セマンティクスを望まない限り、日と曜日の両方を制限しないでください。「1 月の毎週月曜日」が欲しいなら `0 0 * 1 1`（日は `*`）と書き、「毎月 1 日」が欲しいなら `0 0 1 * *`（曜日は `*`）と書きます。POSIX の OR ルールでは `0 0 1 * 1` は毎月 1 日と毎週月曜日の両方で実行されるため、ほぼ確実に意図と異なります。デプロイ前に次回実行プレビューを確認すればこの誤りを検出できます。

スケジュールのタイムゾーンを明示的に固定

モダンなスケジューラはスケジュール定義内でタイムゾーンを固定できます: crontab 先頭の `CRON_TZ=America/New_York`（vixie cron 3.0 以降）、Kubernetes CronJobs 1.27 以降の `spec.timeZone: "America/New_York"`、AWS EventBridge Scheduler の `ScheduleExpressionTimezone` を含むスケジュール式など。サーバーのデフォルトに頼らずタイムゾーンを明示的に固定しましょう — サーバーのタイムゾーンはインフラ移行時に予告なく変わることがあります。

負荷を :00 ではなく複数の分に分散

重要度の低いジョブで `0 * * * *`（毎時 0 分）を多用するのは避けましょう — 規模が大きくなると、ちょうど :00 にスケジュールされた多数のジョブで負荷スパイクが発生します。各ジョブにランダムな分オフセット（`23 * * * *`、`41 * * * *`）を割り当てて負荷を分散します。日次ジョブも同様で、多くのジョブが 3:00 に集中する場合、`0 3 * * *` よりも `30 3 * * *` の方がデータベースに優しい設計です。

ジョブを冪等にする

cron にはリトライも重複防止も取りこぼしリカバリもありません。ジョブは何度実行しても安全（冪等）で、自己チェック可能であるべきです。「9 時にレポート送信」ではなく「今日のレポートが未送信なら送信する」と設計しましょう — ダウンタイム、誤った二重スケジュール、並行実行のいずれからも自己回復します。冪等性はスケジューラではなくジョブの性質であり、最も重要な信頼性プラクティスです。

重要なスケジュールにはハートビートを追加

cron のサイレント失敗は最大の弱点です — スケジュールが発火しなくても誰も気付きません。重要なジョブには、実行終了時にハートビートサービス（Healthchecks.io、Cronitor、Dead Man's Snitch など）へ ping させ、想定の ping が届かないときにアラートしてもらいましょう。これでジョブの失敗もスケジュール自体の不発も検出できます。無料枠で個人や小規模チームの大半のニーズをカバーできます。

リリース前に次回実行プレビューで検証

新しい cron スケジュールをデプロイする前に、本ツールのプレビューで今後 5 回の実行日時を確認しましょう。Local と UTC を切り替えます。意図通りの時刻に発火するか — 5 分早すぎないか、間違った日でないか、大事にしていた週末をスキップしていないかを確認します。プレビューは最も安価な本番テストです。

よくある質問