GitHub Actions のスケジュールのワークフローが何時間も遅れる・動かない：2026年8月末から・自分の側の確かめ・外からの起動
2026年8月26日・27日から、schedule のイベントが何時間も遅れて始まる、または実行がまったく作られない、という公開の報告が多く出ています。push と workflow_dispatch はふつうに始まります。あるプロジェクトが10月28日に測ったところ、1時間ごとの 17 * * * * は1日約24回から4〜6回に減り、UTC の 06:23 の毎日の実行は UTC の 10:42〜15:41 に始まっていました（knowledge-medium #1458）。8月27日からのいちばん長いスレッドには GitHub の担当者の返事がなく（コミュニティのディスカッション #206019）、同じプロジェクトは GitHub Status にスケジュールの障害を見つけていません。GitHub のドキュメントにあるのは、負荷が高いとき、特に毎時の始まりにはこのイベントが遅れることがあり、待っているジョブが落とされることもある、ということだけです。
見え方
エラーは出ません。作られたスケジュールの実行は不ぞろいな時刻に始まり、抜けた回は何も残しません。実行もログも API の記録もありません。cron: "0 * * * *" の最後の5回のスケジュールの実行は、次の時刻に始まっていました（#206019・9月2日）：
2026-09-02T06:34:35Z 2026-09-02T01:48:32Z 2026-09-01T23:38:58Z 2026-09-01T21:33:37Z 2026-09-01T18:57:33Z
落とされた回は跡を残さないので、実行の一覧だけでは「落とされた」と「最初から組まれていない」を分けられません。まず下の確かめで、自分の側の原因を外します。
自分の側の確かめ（読むだけ）
- スケジュールの実行だけを並べます：
gh run list --workflow FILE.yml --event schedule --limit 50 --json createdAt,status,conclusion。間が空いているなら実行が作られていません。あいだに結論がcancelledの実行があるなら、次の項目です。 concurrencyのグループは、既定では待っている実行を1つしか置きません。実行中のものの後ろに新しい実行が並ぶと、前から待っていた実行はキャンセルされます。1回の実行が間隔より長くかかると、ほとんどの回がキャンセルで終わります。queue: maxなら、キャンセルせずに最大100件まで待たせられます（GitHub の concurrency のドキュメント）。- ワークフローの状態：
gh api repos/OWNER/REPO/actions/workflows/FILE.yml --jq .state。disabled_inactivityは、公開リポジトリで60日間動きがなかったことを表し、Actions のタブに「This scheduled workflow is disabled because there hasn't been activity in this repository for at least 60 days.」と出ます。disabled_forkは公開リポジトリのフォークで、スケジュールは既定で止まっています。gh workflow enable FILE.ymlで戻せます。 - ワークフローのファイルは既定のブランチに要り、実行はそこの最後のコミットを使います。別のブランチで cron を変えても、既定のブランチの名前を変えても、既定のブランチのファイルがそうなるまで何も変わりません。
- cron は、項目に IANA の名前の
timezone:（たとえばtimezone: "Asia/Tokyo"）が無ければ UTC で読まれます。いつも同じ時間数だけ遅れるなら、たいてい cron を現地の時刻で書いています。 - いちばん短い間隔は5分で、
@dailyや@hourlyなどの短い書き方は使えません。 - GitHub は
0以外の分を勧めています。ただ8月からは、:17・:23・:37の実行も遅れたという報告があり、分をずらす効き目は前より小さくなっています。
GitHub のスケジューラーのせいなら
上がすべて問題なく、workflow_dispatch ならすぐ始まるなら、ワークフローをどう書いてもスケジュールは時刻どおりになりません。必ず動かしたいジョブは GitHub の外の時計から始め、スケジュールは控えに残します：
gh workflow run FILE.yml --ref main
- REST なら
POST /repos/OWNER/REPO/actions/workflows/FILE.yml/dispatchesに{"ref":"main"}です。classic のトークンはrepoのスコープ、fine-grained のトークンはそのリポジトリの Actions への書き込みが要ります。ワークフローのon:にworkflow_dispatchが要ります。 - 遅れて動いても2回動いても困らないジョブにします。何を処理するかは、始まった時刻ではなくデータから決めます。
- スケジュールの実行がどの回のものかを知るには、回ごとに cron の行を分けます。
github.event.scheduleに、起動した行が入ります（#210111）。
見分け方
- 実行は時刻どおりに作られたのに「Waiting for a runner to pick up this job」で待っている：スケジュールではなく、ランナーが足りない話です（ランナーを待ち続けるジョブ）。
- 実行がジョブ無しで Queued のまま、キャンセルもできない：止まらない実行と force-cancel。
- 1つのリポジトリだけで、push やプルリクエストも含めてどのイベントでも実行が作られず、ほかのリポジトリは動く：リポジトリかアカウントの問題で、見られるのは GitHub Support だけです（#212022）。
ワークフローの実行を IntelliJ IDEA から見るなら
Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べるので、毎晩の実行が最後にいつ始まったかがすぐ分かり、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。
GitHub・GitHub Actions は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：「Waiting for a runner to pick up this job」 · 「Workflow does not have 'workflow_dispatch' trigger」 · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English