GitHub Appのトークンで一部が誤って404に 10月の障害は20件目

GitHub Appで動く自動の処理のうち、100回に1回あまりが「見つからない」で失敗していた時間がありました。日本時間2026年10月27日の15時55分から17時1分までです。GitHubは同じ日の17時、状況ページにこの障害の報告を載せました。対象はGitHub Appのサーバー間のトークンで認証したAPIとgitの要求で、Actionsのトークンは含みません。

誤った404は、ふだんの最大5.3倍

報告によると、認証したgitの操作で誤って404を返した割合は、平均で1.24%、最も多いときで2.49%でした。ふだんの2.6倍と5.3倍にあたります。APIの要求でも失敗が増えたとしていますが、APIだけの割合は書かれていません。

経過を日本時間に直すと、次のとおりです。

報告は、影響は出ていたものの、起きている間は検知されなかったと書いています。

状況ページの報告は、影響がほぼ終わってから1回載っただけです。障害の最中に状況ページを見ても、手がかりは無かったことになります。

移行と大量の削除が重なり、複製が1時間遅れた

原因は、予定していたメンテナンスでした。GitHubは、IADとAzure Central USのデータセンターにある2つのMySQLのクラスターの間で、7つの表を移していました。そのうち1つが、GitHub Appのサーバー間のトークンに使うインストールの記録の表です。

ただ、この日は同じ表で、定期の片付けの処理が約5,900万件の記録を消していました。移行に使うgh-ostというツールの複製が追いつかず、クラスターの間の遅れは最大1時間に。遅れたまま読み取りを新しいクラスターに切り替えたため、トークンの確認に要る記録を引けない要求が出た、という流れとみられます。

GitHubは、ここ数か月で同じような移行を何度か済ませていて、目立った影響は無かったとしています。再発を防ぐため、移行の前に重なる片付けの処理を止めることと、複製の遅れが大きいときは読み取りの切り替えを止めることを、手順と自動化に入れるそうです。

404は「無い」とは限らない

この障害で気をつけたいのは、エラーが404だったことです。GitHubの説明では、非公開のリソースに正しく認証できていない要求を送ると、403 Forbiddenではなく404 Not Foundを返します。非公開のリポジトリがあることを、外に知らせないためです。

つまり、その時間に自動の処理が受け取った「Not Found」は、リポジトリやブランチが消えたのではなく、トークンが一時的に通らなかったことを示していたのでしょう。

困るのは、404を「無い」と決めて動く処理です。ミラーやバックアップの仕組みが「元が消えた」と見て写しを消す、同期の仕組みが作り直す、デプロイの仕組みが失敗として次の手順を飛ばす。こうした動きが起こりえます。GitHubの報告は、利用者の側で何が起きたかには触れていません。自社の処理がどう作られているかは、一度見ておきたいところです。

影響を受けるのは、GitHub Appで動く処理

対象になりうるのは、次のような処理です。

• GitHub Appとして登録した社内のbotや、自社で作った連携の仕組み。インストールのトークン（installation access token）でAPIやgitを使うもの
• GitHubの外で動くCIやデプロイの仕組みのうち、GitHub Appで認証しているもの
• GitHub Appとしてインストールした外部のサービス
• Actionsのワークフローの中で、自社のGitHub Appのトークンを作って使っているもの

報告が対象にしていないのは、Actionsの標準のトークン（GITHUB_TOKEN）です。個人のアクセストークンやSSHの鍵、OAuth Appのトークンについては、何も書かれていません。その時間に処理を動かしていなかった会社は、気にしなくてかまいません。

27日夕方のログで確認すること

1. 10月27日15時55分から17時1分の間に、GitHub Appで動く処理が404で失敗していないかを、CIやbot、デプロイのログで探します。
2. 見つかったら、その処理をもう一度動かし、途中で止まったままのものが無いかを見ます。ミラーや同期の仕組みは、写しが消えたり作り直されたりしていないかも確認します。
3. 404を受けたときの動きを見直します。存在するはずのリポジトリで404が出たら、すぐに「無い」と決めず、間をあけて何度か試し直すようにします。消す、作り直すといった戻しにくい処理の前には、特に確認を挟みたいところです。
4. 監視では、GitHubのAPIの応答を状態コードごとに数え、404が急に増えたら知らせるようにします。今回は状況ページに頼れませんでした。
5. ついでに、GitHub Appに与えている権限が多すぎないかも見ておくとよいでしょう。考え方はGitHub、Appの最小権限管理を改善 自動連携の権限を見直しにまとめています。

10月の障害は20件目

GitHubの状況ページの障害の記録を10月1日から数えると、今回で20件目です。同じ27日の未明、2時59分から3時40分（日本時間）にも、REST APIの応答が遅れ、ChecksやActions、Issues、プルリクエスト、GraphQLの一部で遅れや時間切れが起き、通知も遅れていました。18件目までは、GitHubでPR・Webhookが遅延 監査ログは最大110分遅れ、10月13件目の追記で並べています。

障害の多い月は、状況ページの知らせを待つより、自社のログで先に気づける作りにしておくほうが安心です。