GitHub Actions 發生事故 （★ 100 分）
GitHub 於 2026 年 10 月 5 日發生影響 Actions 與 Pages 的事故。GitHub Actions（GitHub 的持續整合與持續交付 CI/CD 自動化服務）最初出現效能下降，隨後確認 GitHub 託管執行器（hosted runners）派發工作與啟動工作流程發生延遲及失敗，使不同執行器組態的自動化流程無法及時開始。事故期間，部分帳號的儲存庫清單、授權與帳務頁面也無法存取。
GitHub 在當日 21:32 UTC 表示已套用緩解措施，排隊中的工作逐步清除，新工作不再延遲，並預期執行器將完全恢復；Actions 於 21:54 UTC 恢復正常，Pages 於 22:40 UTC 恢復，事故在 22:49 UTC 宣告結束。GitHub 表示將在完成後公布詳細的根本原因分析，但事件公告本身尚未交代故障成因。
Hacker News 討論普遍認為 GitHub Actions 的故障已過於頻繁，許多人甚至認為「長時間沒有事故」才值得成為新聞。有留言指出，美國、歐洲、澳洲與日本等標榜資料落地與隔離的 GitHub Enterprise Cloud 執行個體似乎同受影響，質疑這些區域部署是否仍共用關鍵單點故障。也有人注意到，事故公告提及的儲存庫清單、授權及帳務異常，未在狀態頁其他元件中清楚呈現。
不少使用者正評估替代方案，例如 GitLab、Gitea、Forgejo，或改用其他 CI 服務與自行代管執行器。有公司即使已將執行器移往外部供應商，仍因 GitHub 的派工作業未恢復而無法啟動工作；討論者因此指出，自行代管硬體只能避開 GitHub 託管執行器不足，無法避開 GitHub Actions 控制平面（control plane，負責接收工作流程並派發工作的中樞）故障。另有使用者分享，以舊硬體、Mac mini 或低價雲端主機搭配 Kubernetes（容器編排平台）與 ARC（Actions Runner Controller，管理 Actions 執行器的工具）自行建置 CI，可降低費用並縮短流程時間，但仍需設計脫離 GitHub 派工機制的備援路徑。討論也將近年 AI 輔助開發帶來的大量提交、平行開發與 CI 測試需求，視為平台負載持續攀升的可能因素之一。
👥 63 則討論、評論 💬
https://news.ycombinator.com/item?id=49969961