GitHub API 認證事件 2026 年 6 月 10 日

2026 年 6 月 10 日，GitHub 經歷了顯著的服務降級，導致約 15% 的 API 流量出現斷斷續續的認證失敗。此事件產生了錯誤的 401 回應，觸發了第三方應用程式整合中不必要的認證流程，並干擾了各種開發者工作流程。

事件時間線與解決方案

GitHub 在 2026 年 6 月 10 日 16:39 UTC 前解決了影響 API 請求與「Issues」服務的認證問題。事件的時間線如下：

• 15:20 UTC：GitHub 開始調查多項服務受影響的效能報告。
• 15:23 UTC：API 請求正式被標記為可用性下降。
• 15:27 UTC：「Issues」服務被標記為效能下降。
• 15:46 UTC：「Issues」服務的降級已緩解，調查持續針對 15% API 流量的認證失敗進行。
• 16:21 UTC：GitHub 確認其基礎設施中有問題的元件是斷斷續續 401 回應的原因。
• 16:36 UTC：影響 API 請求的降級已緩解。
• 16:39 UTC：事件宣告已解決。

對開發者工具與整合的影響

401 認證錯誤的斷斷續續特性導致 GitHub 生態系統廣泛受擾。由於系統回傳的是認證失敗而非伺服器錯誤，許多工具會自動嘗試重新認證，形成失敗登入的循環。

受影響的服務與擴充功能

使用者在以下領域報告了失敗情況：

• IDE 擴充功能：GitHub Pull Requests VS Code extension 以及其他 GitHub 整合的 IDE 工具出現重複的登入提示。
• CI/CD 與自動化：CodeQL 動作與 Heroku 認證連線因認證錯誤而失敗。
• C&C 工具：gh CLI 工具受到影響，導致依賴 CLI 進行認證的使用者的遠端 git 操作受阻。
• 瀏覽器擴充功能：Refined GitHub Chrome extension 出現服務中斷。
• 行動裝置：GitHub iOS 應用程式意外將使用者登出。

社群回饋與技術批評

Hacker News 的開發者討論了此事件的影響，並有多位指出錯誤處理方式的技術缺失。

錯誤代碼管理不當

有使用者指出，使用 401（未授權）而非 500（內部伺服器錯誤）特別具破壞性：

I'd much prefer to get a 500 than a 401 if there is something broken in the server. This wasted a solid hour of my day. 如果伺服器有問題，我寧願收到 500 而不是 401。這浪費了我整整一小時的時間。

狀態頁面準確性

對 GitHub 狀態頁面如何分類事件有批評。部分使用者認為，由於認證被歸類於「API」，狀態頁面可能未明確顯示依賴該認證的其他服務（如 gh CLI）的停機時間，可能導致正常時間統計被抬高。

Their status pages are not well defined, but they treat them as such, leading to inflated uptime numbers. 他們的狀態頁面定義不清，但卻如此處理，導致正常時間數字被抬高。