8 月 6 日，GitHub Actions 和 Pages 再次大规模服务降级，Actions 完全不可用超过 5 小时，webhook 停发，连自托管 runner 也因调度层故障无法工作。Pages、Copilot code review、Copilot coding agent 全部受影响。从检测到完全恢复，大约 12 小时。

这是 2026 年 8 月的第六起事故，其中四起与 AI/Copilot 服务相关。

GitHub 员工 kdaigle 在 HN 讨论中贴出了一组数据：2025 年全年 10 亿次 commit。现在，每周 2.75 亿次，全年预计 140 亿次。GitHub Actions 从 2023 年的每周 5 亿分钟，到 2025 年的 10 亿分钟，再到最近一周的 21 亿分钟。

「14 倍的请求量增长，只用了几个月。」

90 天可用性已经跌到了 93.91%。上一次月度可用性达到四个九，是 2024 年 11 月。

社区讨论集中在两个方向。一个是技术层面：GitHub 正在向 Azure 迁移基础设施，这是一个多年的工程，稳定性下降是否与此有关？另一个是更根本的问题——AI Agent 的 commit 量暴增正在压垮平台。（相关阅读：GitHub CTO 谈平台可用性：AI 驱动开发使流量暴增，基础设施从 10 倍扩容至 30 倍）

这不是推测。GitHub Copilot Coding Agent 本身就是这次事故中受影响的服务之一。AI 写代码、AI 提交、AI 触发 CI pipeline——整个链条在自我加速。一个人类开发者一天可能推几次，一个 AI agent 可以连续不断地推。140 亿次 commit 意味着什么？意味着平均每秒 440 多次 push。

事故的直接原因是 runner 被分配了已经失效的 job，陷入重试循环，同时拖垮了 GitHub 托管和自托管的 runner。但真正的压力来自底层：调度系统、存储层、网络带宽都在被 AI 驱动的负载推向极限。

有人贴出了迁移方案：Forgejo、GitLab、自建 Gitea。讨论中一个反复出现的观点是，GitHub 的集中式架构可能撑不住指数级增长的 AI 工作负载。但另一些人指出，GitLab 的 CI 系统也谈不上稳健，迁移只是换一个地方忍受断线。

事故解决后，GitHub 表示 Actions Runner 和 ARC 的未来版本会加入自动恢复机制，避免手动删 pod。但根本问题——平台承载能力 vs AI 负载增长速度——没有答案。

参考来源：

• GitHub Actions and Pages are experiencing degraded availability - GitHub Status
• HN 讨论