仓库内容API降级
2026年9月4日，大约在UTC时间21:45至22:07之间，部分用户在仓库操作中遇到了错误和延迟升高的问题。该事件已于UTC时间22:23完全解决。<br /><br />原因是容量变更将我们的一个集群扩展到了额外的可用区；我们的区域感知流量路由为了性能持续将请求发送到原始区域，导致一小部分服务器过载，而新增容量却处于空闲状态。我们通过回滚变更并让流量重新平衡解决了该事件。<br /><br />我们正在改进按区域的容量保障、跨区域减载以及多区域变更的预生产测试，以防止再次发生。
原文On September 4, 2026, between approximately 21:45 and 22:07 UTC, some users experienced errors and elevated latency for repository operations. The incident was fully resolved at 22:23 UTC.<br /><br />The cause was a capacity change that spread one of our clusters across additional availability zones; our zone-aware traffic routing kept sending requests to the original zone for performance, overloading a small set of servers while the new capacity sat idle. We resolved the incident by reverting the change and letting traffic rebalance.<br /><br />We are improving per-zone capacity guarantees, cross-zone load-shedding, and pre-production testing of multi-zone changes to prevent recurrence.
我们正在调查部分GitHub服务性能受影响的相关报告。
原文We are investigating reports of impacted performance for some GitHub services.
关于这些数据
GitHub的故障事件数据从哪来？
全部来自GitHub 官方状态页的公开接口，由本站每 5 分钟同步一次，保留最近 90 天。事件标题、时间、影响级别与更新记录均为官方原文，本站不做改写；点详情页底部的链接可回到厂商原始记录核对。
顶部的组件状态条怎么看？
每一格是一天，绿色表示GitHub 官方状态页当天未记录异常，黄色表示部分降级，红色表示当天有较大故障，灰色表示该组件当时还没有数据。右侧的可用率是官方口径的 90 天统计，与状态总览页显示的是同一份数据。
为什么有的服务查不到历史？
本页只收录对外提供官方状态页的服务。没有公开状态页的厂商（多数国产大模型属于此类）无法取得可信数据，本站不做自建拨测去猜，因此也不会出现在状态总览里。
持续时长怎么算？
按官方标注的开始时间到恢复时间计算；尚未恢复的事件按「至今」计算并标为进行中。跨天的事件在状态条上会覆盖它经过的每一天。
完整的服务清单与实时状态见状态总览。