【速報 2026年8月27日】GitHub ActionsとPull Requestで遅延・タイムアウト|ワークフロー起動に影響

GitHubの公式ステータスは、GitHub ActionsとPull Requestに関する遅延・タイムアウトを「調査中」の障害として公表しています。2026年8月27日朝の時点で、Pull Requestイベントをきっかけに起動するワークフローを中心に、開始の遅れや起動失敗が発生しています。

現在わかっている影響

GitHubの障害開始は日本時間で2026年8月27日 07:56、公式の最新更新は2026年8月27日 07:57です。GitHub Statusでは影響度をMinorとしており、現在も調査・緩和作業中です。

公式発表によると、影響が出ているのはPull RequestイベントをトリガーにしたActions workflow runsです。具体的には、開始まで5分を超える遅延が約20%で起き、最大4%はワークフロー自体が起動しない場合があります。PR画面が開けることと、CI/CDやレビュー自動化が通常どおり完了することは別なので、重要な変更ではActionsの実行履歴も確認してください。

確認項目	現時点の公式情報
障害名	Incident with Actions and Pull Requests
影響範囲	Actions、Pull Requests
主な症状	PRイベント由来のworkflow runの開始遅延、タイムアウト、起動失敗
公式の定量情報	約20%で5分超の開始遅延、最大4%で起動失敗
現在の状態	GitHubが調査・緩和中

仕事でGitHub Actionsが止まった時の確認手順

1. PR番号・コミットSHA・実行URLを先に残す

まず該当PRの番号、対象コミットのSHA、Actionsの実行URLと開始時刻を控えます。障害中に何度も再実行すると、後から「どの実行がデプロイや外部連携を行ったか」を追いにくくなります。通知、リリース、課金処理、データ更新を含むジョブは特に慎重に扱ってください。

2. Actions画面でQueued・In progress・失敗の違いを確認する

Queuedのまま長時間変わらない場合は、今回の開始遅延の影響を受けている可能性があります。失敗表示でも、設定ミスやテスト失敗ではなく、イベントが起動されなかったケースと混同しないようにします。個別ジョブのログに通常のアプリケーションエラーがある場合は、GitHub側の障害だけが原因とは限りません。

3. 再実行は副作用を確認してから行う

テストだけのワークフローなら、公式ステータスと実行履歴を確認したうえで再実行が選択肢になります。一方、productionへのデプロイ、外部API送信、データ移行、通知送信を行う処理は、すでに一部が完了している可能性があります。担当者間で実行担当を決め、二重実行にならないことを確認してから再実行してください。

4. マージ判定とリリース判定を分ける

必須チェックが遅延している間は、PRのマージ可否と本番リリース可否を同じ判断にしないほうが安全です。緊急変更であっても、誰が例外承認をしたか、どのチェックが未完了かを記録しておくと、障害復旧後の確認がしやすくなります。

起動しないワークフローを切り分ける時の見方

今回の障害では、Pull Requestの作成、更新、再オープンなどのイベントを受けて起動する処理が中心です。PRの画面でコミットが追加されているのに、通常なら数秒から数分で表示されるチェックが出ない場合は、まずイベント発生時刻を確認します。その後で、リポジトリ固有の条件、たとえば対象ブランチ、パスフィルター、forkからのPR、Required checksの設定変更がないかを確認してください。

一方で、手動実行したworkflow_dispatchや定時実行まで同じ障害だと断定することはできません。手動実行だけが失敗する、特定のリポジトリだけで失敗する、実行後すぐにアプリケーション固有のエラーが出る場合は、GitHub公式の障害と別に、権限、Secrets、ランナー、workflow YAMLの変更も確認対象です。障害の時間帯と症状が似ていても、すべてをサービス側の原因として扱わないことが、復旧後の原因調査を短くします。

復旧を確認した後に行う照合

GitHub Statusが復旧済みになった後も、障害中に作られたPRやデプロイを一度だけ棚卸しします。まず、開始時刻が障害中だったワークフローを一覧にし、Queuedのまま残っていないか、同じコミットに複数の実行がないかを確認します。次に、成功表示だけで判断せず、成果物、デプロイ先のバージョン、通知先、外部サービスの更新結果まで照合します。

特にリリース自動化では、再実行により同じタグ、同じパッケージ、同じ通知が複数回作られていないかを確認してください。失敗した実行を消す前に、実行URLとログの時刻をチームの障害記録へ残しておくと、後日同様の遅延が起きた際に比較できます。恒久対応が必要かどうかは、GitHub公式の障害終了後に通常時のPRで再現しないことを確認してから判断します。

ユーザーへの影響を小さくする運用

顧客向けサービスや社内システムの変更をGitHub Actionsで配布している場合、CIの遅延は「変更が反映されない」「承認待ちが長い」「復旧対応が進んでいない」と受け取られることがあります。外部へ案内する必要があるときは、GitHubの内部機能名だけで終わらせず、影響する業務、保留中の作業、次回の確認時刻を短く示します。確定していない復旧時刻を約束しないことも大切です。

社内では、障害発生中に誰が公式ステータスを監視し、誰が再実行の判断をするかを分けると、重複対応を避けられます。緊急デプロイのためにブランチ保護やレビューを恒久的に緩めることは避け、例外対応が必要なら対象PRと期限を限定して記録します。障害が解消したら例外設定を戻し、通常の確認手順へ復帰してください。

チームへの共有文に含めるとよい内容

社内チャットや顧客連絡では「GitHub Actionsの遅延によりCI/CDの開始が遅れている」「現時点ではPull Requestイベント由来の実行に影響」「設定変更の障害とは断定していない」「公式復旧を確認後に再実行する」といった形で、事実と対応方針を分けて伝えると混乱を抑えられます。根拠のない復旧見込みや、GitHub全体が使えないという表現は避けてください。

よくある質問

GitHubにログインできるなら障害ではありませんか?

いいえ。今回の公式情報はActionsとPull Requestsの機能低下です。GitHubの画面閲覧やログインができても、ワークフロー起動・CI・自動デプロイの処理に影響することがあります。

ワークフローをすぐ再実行してよいですか?

テスト処理だけなら比較的判断しやすい一方、デプロイや外部サービスへの送信を伴う場合は二重処理の危険があります。実行履歴と外部側の結果を確認してから対応してください。

復旧状況はどこで確認できますか?

GitHubの公式ステータスを優先してください。国内で発生している通信・決済・業務ツールの障害は、システム障害の最新一覧でも継続して整理しています。

公式情報

GitHub Status: Actions and Pull Requests incident

最終確認: 2026年8月27日 07:57(GitHub公式ステータスの更新時刻を日本時間へ換算)