GitHub Actions の schedule（cron）が定刻に実行されない
schedule トリガはデフォルトブランチでのみ動き、高負荷時間帯は遅延し、public リポジトリでは 60 日間活動が無いと自動無効化される。
cron は UTC 基準なので JST との 9 時間差にも注意する。
#github-actions#schedule#cron#workflow#trigger
公開: 更新:
要約
on: schedule の cron が定刻に実行されないときは、(1) デフォルトブランチに無い、(2) 高負荷時間帯の遅延、(3) 60 日無活動による自動無効化、(4) UTC とローカル時刻の取り違え、の順に疑う。公式ドキュメントのとおり、schedule は「正確な定刻実行」を保証する仕組みではない。
よくある原因
- デフォルトブランチに無い: scheduled workflow はデフォルトブランチ（通常
main）上の定義だけが評価される。
feature ブランチに置いたまま「動かない」となるのが定番。 - 高負荷時間帯の遅延: 毎時 0 分はワークフロー実行が集中するため、遅延やスキップが起きやすいと公式に明記されている。
- 60 日無活動で自動無効化: public リポジトリでは、60 日間リポジトリに活動が無いと scheduled workflow が自動で無効化される。
- UTC とのズレ: cron は UTC 基準。
0 0 * * *は JST では朝 9 時に相当する。 - 構文ミス: フィールドが 5 個でない、対応していない拡張記法を使っている、などはそもそもトリガ登録されない。
解決策
1. デフォルトブランチにマージする
on:
schedule:
- cron: "17 0 * * *"この定義が main に入って初めてスケジュールが有効になる。
ブランチで動作確認したい場合は workflow_dispatch を併記して手動起動でテストする。
2. 半端な分を指定する
毎時 0 分（0 * * * * など）は混雑のピーク。17 */6 * * * のように分をずらすと遅延の影響を受けにくい。
数分〜数十分の遅延は仕様として許容する。
3. 無効化されたワークフローを再有効化する
Actions タブで該当ワークフローを開き、無効化の表示があれば Re-enable workflow を押す。
活動が長期間途絶えるリポジトリでは定期的な再有効化が必要になる。
4. UTC で時刻を計算する
JST の 6:00 に動かしたいなら 0 21 * * *（前日 21:00 UTC）と書く。
タイムゾーン指定の機能は無いため、必ず UTC に換算する。