GitHub Actionsのcronが動かない・遅れる時の対処

最終更新: 2026-08-15

GitHub Actionsのschedule（cron）は、一般的なサーバーのcronと違う制約があります。最初に「まったく動かない」「時刻だけ違う」「たまに遅れる」のどれかを分けると、原因を早く絞れます。

まず1分で確認する5項目

• ワークフローファイルがデフォルトブランチにあるか
• timezoneを指定したか。省略した場合はUTCとして読んでいるか
• 最短間隔の5分より短い指定になっていないか
• 公開リポジトリが60日以上動いていない状態ではないか
• 毎時0分など、負荷が集中しやすい時刻を指定していないか

原因1: timezone未指定でUTCになっている

GitHub Actionsのscheduleは、timezoneを省略するとUTC基準です。現在はIANAタイムゾーン名を指定できるため、日本時間なら次のように書けます。

on:
  schedule:
    - cron: '0 9 * * 1-5'
      timezone: "Asia/Tokyo"

既存のUTC指定を使う場合は、日本時間から9時間引きます。たとえば日本時間9時はUTC0時です。詳しくはタイムゾーン問題の記事とGitHub Actions用ページで確認できます。

原因2: デフォルトブランチにない

scheduleトリガーはデフォルトブランチ（通常main）上のワークフローファイルだけが有効です。featureブランチに置いたままだと動きません。

原因3: 60日間の無操作で自動停止

公開リポジトリでは、リポジトリに60日間アクティビティがないとscheduleが自動的に無効化されます。Actions画面で無効化状態を確認し、必要ならワークフローを再び有効にします。

原因4: 実行の遅延・スキップ

GitHubは、高負荷時にはscheduleの実行が遅れ、一部のキュー済みジョブが破棄される可能性があると案内しています。特に毎時0分は負荷が集中しやすいため、厳密な正時が不要なら7 * * * *や13 * * * *のように分をずらします。

※ 仕様の確認にはGitHub公式のscheduleドキュメントを使っています。YAML例と式の検証はGitHub Actions用ページにまとめています。