事件時間線：從調查到分階段恢復

GitHub約在 13:40 UTC、也就是美東時間 上午9:40 開始調查效能問題。 問題很快擴大至開發團隊用來存取程式碼、審查變更、執行自動化流程與發布軟體的多項服務。

GitHub稍後表示已找出涉問題元件並採取修正措施。公司在美東時間 中午12:36 發布的更新指出，平台已出現明顯恢復跡象，但服務尚未完全穩定。

恢復並非所有服務同步完成。GitHub的狀態頁顯示，多項主要服務已恢復運作時，Copilot在部分應用程式中仍有驗證問題。 其他事件紀錄則將整體中斷時間列為約 13:28至21:15 UTC，意味著從最初出現問題到整體事件結束，持續時間明顯長於最嚴重的服務劣化階段。

影響有多嚴重？

GitHub公布的錯誤率，是目前最清楚的影響指標：

• 網頁體驗與 API 流量： 錯誤率約 20%。
• 封存檔與原始儲存庫內容下載： 錯誤率約 50%。
• 開發者服務： Pull Requests、Issues、Actions、Webhooks、Git 操作與 Pages，在不同時段出現效能下降或無法使用。
• AI 程式開發協助： GitHub Copilot受到影響，而且在多項核心服務恢復後，仍一度是持續處理中的問題。
• 企業身分管理： SAML、OIDC 驗證、SCIM 佈建與 Team Sync均傳出受影響，部分組織可能無法可靠地登入使用者或管理存取權限。

這些數字代表的是請求錯誤率，不是所有GitHub使用者中斷服務的比例。API錯誤率20%，不等於正好20%的客戶完全離線；下載錯誤率50%，也只適用於受影響的下載請求，並不代表所有儲存庫流量都失敗。

為什麼發生在週一早上，衝擊特別大？

事故發生在美國週一早上，正好碰上許多工程團隊開始一週工作的時段。對不少團隊而言，早上的工作循環可能同時包括存取程式碼、檢視與合併變更、啟動持續整合與部署流程，以及處理自動化通知。

這次受影響的正是 Actions、Pull Requests、API與Webhooks等相互串連的服務，因此團隊可能不是只有某一個功能暫時失效，而是在程式碼存取、審查、測試與發布等多個環節同時遇到問題。

外部故障回報平台的數字也因時間與統計方式不同而有所差異。一份報導稱，Downdetector在太平洋時間上午8:12前收到超過 10,000筆回報；另一份恢復報導則指出，回報高峰接近 3,000筆。 這些數字不應被視為受影響使用者的精確人數，因為故障追蹤平台統計的是使用者提交的回報，結果會受到地區、時間與統計方法影響。

GitHub做了什麼？哪些事情仍未解釋？

GitHub的公開更新目前可以確認三件事：

1. 工程團隊調查了多項服務的效能異常。
2. 公司找出一個問題元件，並採取修正措施。
3. 主要平台服務開始恢復後，GitHub仍持續進行緩解作業，包括處理部分應用程式中偶發的Copilot驗證失敗。

但現有證據無法確認該元件的身分、具體修正內容，也無法證明「容量壓力」就是這起8月17日事故的直接原因。AI流量成長與基礎設施限制，確實是GitHub整體可靠性討論的一部分；然而，在官方事後報告公布前，不應把它們當成這起事故已獲證實的根本原因。

這場事故如何反映GitHub在2026年的可靠性問題？

8月事故發生前，GitHub已經歷一段可靠性壓力較高的時期。GitHub公布的7月可用性報告記錄了 8起事件。其中，7月8日的一起事故持續超過7小時，影響Web介面、REST API、GraphQL API、Actions、Packages、Copilot，以及部分Enterprise Cloud環境的 Git 操作。

GitHub也曾說明更廣泛的基礎設施挑戰：流量正快速成長，主要推力之一是AI輔助與代理式開發工作流程。公司的應對方向包括把更多容量移轉至Azure、拆分服務，以及減少共用故障點。 這也說明了服務耦合的風險：當多項功能依賴相同基礎設施時，原本局部的故障可能迅速擴大成平台級中斷。

從容量規模來看，相關報導指出，GitHub原先規劃將容量擴大至當時的 10倍，但到2026年2月已改為需要以當時規模的 30倍進行設計。 另有報導提到，Azure與包括AWS在內的多雲容量規劃正在推進；但這些基礎設施計畫本身，並不能證明它們造成了8月事故。

這使得8月17日的事件不只是「GitHub某個早晨故障」而已。GitHub如今同時是程式碼儲存平台、協作工具、自動化與部署基礎設施、企業身分系統，以及AI程式開發服務。當共用依賴項發生問題時，一起事故就可能同時中斷儲存庫存取、程式碼審查、建置、部署、Webhooks與AI輔助開發。

組織可以從中得到什麼教訓？

這次事故並不能證明開發者即將集體離開GitHub，現有證據也不足以預測一波迫在眉睫的平台遷移潮。但它確實提醒依賴GitHub進行正式環境交付的組織，應重新檢視自己的故障假設。

實務上可考慮：

• 維持儲存庫備份或鏡像；
• 讓CI/CD設定保持可移植性；
• 文件化緊急發布與回復流程；
• 預先確認在SSO、Webhooks或託管Runner無法使用時，團隊如何繼續工作。

這些措施無法消除平台風險，但能降低下一次服務中斷的爆炸半徑。

8月17日事故的最終判斷，仍要等GitHub公布事後報告。在此之前，較穩妥的結論是：GitHub經歷了一場廣泛且具連鎖效應的服務中斷，儲存庫下載與相互連結的開發工作流程受到尤其嚴重的影響；服務以分階段方式恢復，而底層故障原因目前尚未由GitHub公開說明。

事件時間線：從調查到分階段恢復

GitHub約在 13:40 UTC、也就是美東時間 上午9:40 開始調查效能問題。 問題很快擴大至開發團隊用來存取程式碼、審查變更、執行自動化流程與發布軟體的多項服務。

GitHub稍後表示已找出涉問題元件並採取修正措施。公司在美東時間 中午12:36 發布的更新指出，平台已出現明顯恢復跡象，但服務尚未完全穩定。

恢復並非所有服務同步完成。GitHub的狀態頁顯示，多項主要服務已恢復運作時，Copilot在部分應用程式中仍有驗證問題。 其他事件紀錄則將整體中斷時間列為約 13:28至21:15 UTC，意味著從最初出現問題到整體事件結束，持續時間明顯長於最嚴重的服務劣化階段。

影響有多嚴重？

GitHub公布的錯誤率，是目前最清楚的影響指標：

• 網頁體驗與 API 流量： 錯誤率約 20%。
• 封存檔與原始儲存庫內容下載： 錯誤率約 50%。
• 開發者服務： Pull Requests、Issues、Actions、Webhooks、Git 操作與 Pages，在不同時段出現效能下降或無法使用。
• AI 程式開發協助： GitHub Copilot受到影響，而且在多項核心服務恢復後，仍一度是持續處理中的問題。
• 企業身分管理： SAML、OIDC 驗證、SCIM 佈建與 Team Sync均傳出受影響，部分組織可能無法可靠地登入使用者或管理存取權限。

這些數字代表的是請求錯誤率，不是所有GitHub使用者中斷服務的比例。API錯誤率20%，不等於正好20%的客戶完全離線；下載錯誤率50%，也只適用於受影響的下載請求，並不代表所有儲存庫流量都失敗。

為什麼發生在週一早上，衝擊特別大？

事故發生在美國週一早上，正好碰上許多工程團隊開始一週工作的時段。對不少團隊而言，早上的工作循環可能同時包括存取程式碼、檢視與合併變更、啟動持續整合與部署流程，以及處理自動化通知。

這次受影響的正是 Actions、Pull Requests、API與Webhooks等相互串連的服務，因此團隊可能不是只有某一個功能暫時失效，而是在程式碼存取、審查、測試與發布等多個環節同時遇到問題。

外部故障回報平台的數字也因時間與統計方式不同而有所差異。一份報導稱，Downdetector在太平洋時間上午8:12前收到超過 10,000筆回報；另一份恢復報導則指出，回報高峰接近 3,000筆。 這些數字不應被視為受影響使用者的精確人數，因為故障追蹤平台統計的是使用者提交的回報，結果會受到地區、時間與統計方法影響。

GitHub做了什麼？哪些事情仍未解釋？

GitHub的公開更新目前可以確認三件事：

1. 工程團隊調查了多項服務的效能異常。
2. 公司找出一個問題元件，並採取修正措施。
3. 主要平台服務開始恢復後，GitHub仍持續進行緩解作業，包括處理部分應用程式中偶發的Copilot驗證失敗。

但現有證據無法確認該元件的身分、具體修正內容，也無法證明「容量壓力」就是這起8月17日事故的直接原因。AI流量成長與基礎設施限制，確實是GitHub整體可靠性討論的一部分；然而，在官方事後報告公布前，不應把它們當成這起事故已獲證實的根本原因。

這場事故如何反映GitHub在2026年的可靠性問題？

8月事故發生前，GitHub已經歷一段可靠性壓力較高的時期。GitHub公布的7月可用性報告記錄了 8起事件。其中，7月8日的一起事故持續超過7小時，影響Web介面、REST API、GraphQL API、Actions、Packages、Copilot，以及部分Enterprise Cloud環境的 Git 操作。

GitHub也曾說明更廣泛的基礎設施挑戰：流量正快速成長，主要推力之一是AI輔助與代理式開發工作流程。公司的應對方向包括把更多容量移轉至Azure、拆分服務，以及減少共用故障點。 這也說明了服務耦合的風險：當多項功能依賴相同基礎設施時，原本局部的故障可能迅速擴大成平台級中斷。

從容量規模來看，相關報導指出，GitHub原先規劃將容量擴大至當時的 10倍，但到2026年2月已改為需要以當時規模的 30倍進行設計。 另有報導提到，Azure與包括AWS在內的多雲容量規劃正在推進；但這些基礎設施計畫本身，並不能證明它們造成了8月事故。

這使得8月17日的事件不只是「GitHub某個早晨故障」而已。GitHub如今同時是程式碼儲存平台、協作工具、自動化與部署基礎設施、企業身分系統，以及AI程式開發服務。當共用依賴項發生問題時，一起事故就可能同時中斷儲存庫存取、程式碼審查、建置、部署、Webhooks與AI輔助開發。

組織可以從中得到什麼教訓？

這次事故並不能證明開發者即將集體離開GitHub，現有證據也不足以預測一波迫在眉睫的平台遷移潮。但它確實提醒依賴GitHub進行正式環境交付的組織，應重新檢視自己的故障假設。

實務上可考慮：

• 維持儲存庫備份或鏡像；
• 讓CI/CD設定保持可移植性；
• 文件化緊急發布與回復流程；
• 預先確認在SSO、Webhooks或託管Runner無法使用時，團隊如何繼續工作。

這些措施無法消除平台風險，但能降低下一次服務中斷的爆炸半徑。

8月17日事故的最終判斷，仍要等GitHub公布事後報告。在此之前，較穩妥的結論是：GitHub經歷了一場廣泛且具連鎖效應的服務中斷，儲存庫下載與相互連結的開發工作流程受到尤其嚴重的影響；服務以分階段方式恢復，而底層故障原因目前尚未由GitHub公開說明。