GitHub 每個月都會公布一份可用性報告，說明當月平台出了哪些比較大的問題。2026 年 9 月的報告提到兩起事故：一起是 9 月 13 日的資料庫過載，另一起是 9 月 28 日 Copilot 程式碼審查結果沒有正常送出，兩起加起來影響平台將近兩個半小時。
第一起事故發生在 9 月 13 日，一個原本用來清理資料庫的背景工作把共用資料庫的主要伺服器連線數撐爆，因為它的安全機制只盯著備援伺服器的延遲，沒注意到主要伺服器承受的流量，加上資料庫呼叫沒設逾時、失敗後又一直重試，讓問題持續惡化，當時大約 96% 的 issue 與 pull request 建立請求失敗，新帳號註冊失敗率約 90%，Actions 工作流程也有 4% 受影響，歷時約 1 小時 28 分鐘，GitHub 靠降載並暫停該工作恢復服務。第二起事故發生在 9 月 28 日，一次服務更新讓 Copilot 程式碼審查結果沒辦法正常送到使用者手上，審查停在「進行中」狀態長達 30 分鐘到 2 小時，GitHub 最後把這次更新整個回滾才恢復正常，歷時約 52 分鐘。
這份報告值得注意的地方在於 GitHub 把事故原因寫得很具體：第一起問題不是資料庫效能不夠，而是監控指標看錯重點，只看備援延遲卻忽略主要伺服器的即時負載；第二起問題則是服務改版時，不同使用者收到的審查結果版本不一致，卻沒有機制即時發現。GitHub 也公開了後續的改善方向，包括替背景工作加上更合理的容量防護、減少不必要的重試，以及在審查結果傳遞的流程裡加強監控。
這篇屬於 GitHub 自己公司維運層面的事故報告，內容比較偏向大型系統的資料庫設計與監控，不是一般學程式的孩子平常會碰到的題材。不過它示範了一個很好的習慣：出問題之後要老實寫清楚哪裡壞了、為什麼壞、以後怎麼避免，這種「事後檢討」的態度，其實也值得剛開始寫程式的人學習。
開發工具資料庫平台穩定性