Cron デバッグワークフロー

検証なしで cron 行を出荷すると、バックアップが真夜中ではなく正午に走ることをチームが学びます。スケジュールをコードのように扱います。解析、説明、プレビュー。

ステップ 1：行を正規化

• 5 フィールドのみ（プラットフォームが 6 を文書化しない限り）
• 余分なスペースなし。コメント除去（crontab では # backup job は独自行、フィールド内ではない）
• Quartz ? 構文と Unix cron を混在していないか確認

式をパーサーに貼り付け、フィールドごとの分解を読みます。

ステップ 2：人間可読な説明を読む

良い説明が答えること：

• どの分と時に発火するか？
• 日と曜日の両方が制限されているか — OR 意味論が適用されるか？
• これは「毎平日の朝」か、それとももっと奇妙か？

英語（またはローカライズ）要約が意図と一致しなければ、デプロイ前にフィールドを修正してください。

ステップ 3：次回実行時刻をプレビュー

少なくとも 3 から 5 つの upcoming 瞬間を生成：

• プラットフォームの実行タイムゾーン
• UTC（ログと Actions の相関用）

カレンダーと比較 — 特に月末、DST 移行、短い月の周辺。

ステップ 4：プラットフォームドキュメントと照合

質問	アクション
GitHub Actions？	UTC を前提
K8s CronJob？	timeZone を明示設定
Linux crontab？	サーバー timedatectl を把握
6 フィールドエンジン？	翻訳する。盲目コピーしない

よくあるミスチェックリスト

ミス	症状
日曜 7 vs 0 の混乱	曜日が 1 日ずれる
AND を期待して DOM と DOW を両方設定	追加実行
分フィールドの */60	無効または空スケジュール
UTC Actions 向けにローカル 9 時を記述	壁時計で誤実行
長いジョブ + 短い間隔	実行の重複

ステップ 5：ランブックに文書化

式、タイムゾーン、プラットフォーム、オーナー、期待実行時間を記録します。最終実行成功を証明するモニタリングへのリンク。

要点

解析 → 説明 → プレビュー → 文書化。 どのステップも期待と食い違えば止めてください。cron バグは、財務がレポートが 2 回走った理由を聞くまで静かです。

Cron Expression Parser でこのワークフローを実行してください。