GitHub Actions の schedule（cron）で6時47分に予約した実行が、2026年9月9日から毎朝1〜5時間遅れて始まった

毎時0分を避けた6時47分の予約でも、9月9日からは毎朝1時間半以上遅れて、schedule の実行が作られました。作られたあとの待ちは0秒で、手元の Mac から送った起動（workflow_dispatch）は2〜3秒で作られました（2026年10月4日〜13日の6朝）。

時点: 2026年8月20日〜10月13日・GitHub（Free のプラン）・非公開のリポジトリ1つ・ワークフロー1本の schedule。公式の説明は2026年10月13日に読みました（ページに更新日の表記なし）。

症状

ぼくは毎朝の X への投稿と記録の集計を、GitHub Actions（GitHub の上でプログラムを動かす仕組み）の schedule（時刻を決めて動かす起動）で動かしています。時刻は cron（分・時・日・月・曜日の順に空白で区切って並べる書き方）で書きます（既定は UTC〈世界の標準時〉）。

始めた2026年8月20日は日本時間の7時00分（0 22 * * *）で予約し、8月28日に、毎時0分の混む時間を避けるつもりで6時47分（47 21 * * *）にずらしました。

予約した時刻から実行が作られるまでの遅れです（Actions の実行の一覧の、8月20日〜10月13日の55日分）。

9月9日と9月29日に、遅れが段になって増えました。

原因

確かめたこと: 遅れは、実行が作られる前に起きていました。予約の54回とも、実行の記録の「作られた時刻」と「始まった時刻」は同じ秒です。9月9日と9月29日の前後で、ぼくは schedule の行を変えていません（変更の履歴で確かめた）。

公式の説明（Events that trigger workflows の schedule の節）には、混む時間は schedule の起動が遅れることがある、毎時0分は混む、待っている job（実行の中の仕事の単位）が落とされることがある、毎時0分とは別の分にすると遅れにくくなる、と書いてありました。どのくらい遅れるかは書いてありませんでした。

見立て: 9月9日と9月29日の段は、GitHub の側の混み方か予約の扱いが変わったためと見ていますが、確かめていません。8月27日の回は、公式の説明の「落とされることがある」に当たると見ていますが、確かめていません。

直し方（ぼくの場合）

2026年10月3日に、朝の起動を2本にしました。

1. ワークフロー（動かす手順のファイル）の workflow_dispatch（外から起動を送る入口）に、「定時の回として扱う」入力を1つ足す
2. 手元の Mac の launchd（決まった時刻に処理を動かす Mac の仕組み）に、毎朝6時47分に gh workflow run（起動を GitHub に送るコマンド）を走らせる設定を入れる。送れなければ30秒おきに送り直し、最初の1回を含めて6回まで試す
3. schedule の6時47分は消さずに、予備に残す
4. ワークフローの最初に、その朝の定時の回が済んでいれば何もせずに終える工程を足す（遅れて来た回が二重に投稿しないように）

確かめ方

10月4日〜13日の10朝です（実行の一覧と、Mac の起動の記録から）。

Mac から送った6朝は、送り始めて2〜3秒で実行が作られ、6時47分に始まりました。遅れて来た schedule の回は何もせずに終わり、二重に動いた朝は0回です（実行ごとに残している記録は10朝とも1行）。

「なし」の4朝は、前の晩か未明にシステム終了していて、6時47分に Mac の電源が切れていました。この4朝は、遅れて来た schedule の回が本番になりました。

出所

• GitHub Docs「Events that trigger workflows」の schedule の節（2026年10月13日に読んだ・ページに更新日の表記なし）。どのくらい遅れるかは、書いていなかった
• ぼくの作業の記録（2026年8月20日〜10月13日の Actions の実行の一覧・2026年10月3日の調べ・手元の Mac の起動と電源の記録）