GitHub週一（8/17） 發生大規模服務故障 ，包括API、Git Operations、Actions、Issues、Pages、Pull Requests及Webhooks等多項核心服務皆受影響，網站服務與API流量錯誤率一度達20%，儲存庫封存檔及原始內容下載錯誤率更一度達50%。事故自世界協調時間（UTC）8月17日13時40分（台北時間8月17日21時40分）開始，至21時15分UTC（台北時間8月18日5時15分）才完全排除，歷時約7小時35分鐘。

隨著事故持續，GitHub陸續將Actions、Pull Requests、Issues、API Requests、Webhooks、Pages及Git Operations等服務標示為效能或可用性下降。GitHub Actions是GitHub提供的軟體開發自動化服務，可在程式碼更新後自動執行測試、建置及部署等工作，因此故障除了影響開發者存取及協作程式碼，也可能使軟體開發與發布流程受阻。

GitHub在16時36分表示，已找到造成事故的「問題元件」（problematic component）並採取修正措施，主要服務開始恢復；16時59分宣佈API Requests、Actions、Git Operations、Issues、Pages、Pull Requests及Webhooks的異常均已獲得緩解。

不過故障隨後再度出現，Git Operations及Issues先後發生效能下降，API Requests也再次出現可用性問題。GitHub表示，雖已修正問題元件，但多項服務仍有殘餘影響，後期主要集中於零星的身分驗證失敗。GitHub部分停用驗證權杖重試機制後情況改善，最後剩下部分應用程式零星出現Copilot驗證失敗，直到21時15分才宣佈事故完全解決。

GitHub目前尚未公佈造成此次事故的真正原因，僅表示會在完成調查後揭露詳細分析。

這也是GitHub近期再次發生長時間服務事故。 8月6日 GitHub Actions才發生逾9小時故障，當時GitHub在例行更新服務期間發生一連串故障，復原過程又碰上容量及工作分派問題，使服務恢復時間進一步延長。事故高峯時，71%的工作流程發生基礎設施故障，其餘工作流程中也有75%延遲超過5分鐘。

GitHub事後解釋 ，雖然多數Actions工作已在Azure執行，但負責連接GitHub主系統與Actions的服務仍完全運行於GitHub自家資料中心，而自家資料中心容量不足也是事故復原緩慢的因素之一。GitHub因此決定加速將Actions相關服務移往Azure，以取得更多容量，提升因應突發負載的能力。