4 月，我们经历了 10 起事件，导致 GitHub 服务性能下降。

为了提高透明度，我们在 4 月底发布了一篇博客文章，介绍了 4 月 23 日和 4 月 27 日发生的重大事件。我们还采取措施，在 GitHub 状态页面上提供更详细的信息。

感谢您的耐心等待，我们正在推进近期和长期的投入。

4 月 01 日 15:02 UTC（持续 8 小时 43 分钟）

2026 年 4 月 1 日，UTC 14:40 至 17:00 期间，GitHub 的代码搜索服务完全不可用；100% 的搜索查询失败。到 UTC 17:00，服务以降级状态恢复，结果暂时过时；到 UTC 23:45，服务完全恢复并提供最新数据。

在完全不可用的 2 小时 20 分钟期间，100% 的代码搜索请求均失败。UTC 时间 17:00 初步恢复后，搜索能够返回结果，但这些结果未反映当天约 UTC 时间 07:00 之后所做的仓库变更。完整索引于 UTC 时间 23:45 完成追赶。

在对支持代码搜索的消息系统进行例行基础设施升级期间，一项自动化变更被过于激进地应用，导致内部服务之间出现协调故障。这使搜索索引停止，搜索结果开始变得陈旧。在团队努力恢复消息基础设施时，一次非预期的服务部署清除了内部路由状态，使结果陈旧问题升级为完全中断。

我们通过受控重启恢复了消息基础设施，重新建立了服务之间的协调。随后，我们将搜索索引重置到中断发生前的某个时间点。没有仓库数据丢失——搜索索引是由 Git 仓库派生的二级索引，而 Git 仓库完全未受影响。重新索引完成后，所有搜索结果都反映了仓库的当前状态。

我们正在增加更多渐进式升级，并配备更完善的健康检查，以便在问题级联扩散前将其发现；增加部署保护措施，以防止在活跃事件期间发生非预期变更；提供更快速的恢复工具，以缩短服务恢复时间；并改进流量隔离，以防止故障期间意外流量激增造成级联影响。

4 月 1 日 16:06 UTC（持续 4 分钟）

2026 年 4 月 1 日 15:34 UTC 至 16:02 UTC 期间，由于凭证轮换失败，我们的审计日志服务与其后端数据存储失去连接。在这 28 分钟内，审计日志历史记录无法通过 API 和 Web UI 访问。这导致 4,297 个 API 执行主体和 127 名 github.com 用户遇到 5xx 错误。此外，在此期间创建的事件在 github.com 和事件流中最多延迟 29 分钟。没有审计日志事件丢失；所有审计日志事件最终均已成功写入并流式传输。使用具有数据驻留功能的 GitHub Enterprise Cloud 的客户未受此事件影响。

我们在协调世界时 15:40 收到基础设施故障告警——距故障开始六分钟后——并通过重启受影响环境解决了该问题，于协调世界时 16:02 恢复全部服务。由于此次事件，我们完成了多项后续行动，以降低复发风险并改进检测。团队更新并强化了凭据轮换流程，以提高韧性，并帮助防止未来发生类似故障。与此同时，我们增强了监控配置，包括提高分页告警阈值的敏感度，以提升检测速度，并增强运维人员对今后类似问题的可见性。

4 月 09 日 09:50 UTC（持续 25 分钟）和 16:20 UTC（持续 4 小时 16 分钟）

2026 年 4 月 9 日，我们发生了两起事件，分别在 UTC 09:05 至 19:05 之间以及 UTC 16:05 至 20:36 之间，期间 Copilot coding agent 服务出现降级，用户在启动新的 agent 会话时遇到显著延迟。约 84% 的新 agent 会话请求在四个独立的中断波次中出现延迟，队列等待时间峰值达到 54 分钟，而正常基线为 15–40 秒。平均而言，错误率为 83.9%，并在对该服务的请求中峰值达到 97.5%。事件期间，约 22,700 次工作流创建被延迟或失败。

这是由于我们的速率限制逻辑中存在一个错误，该错误将速率限制错误地全局应用于所有用户，而不是将其限定在触发该限制的单个安装范围内。一个促成因素是，某个客户端更新导致 API 流量激增，使对一个内部端点的请求增加了 3–4 倍，从而加速了速率限制额度耗尽。第二起类似事件同样是由于某个内部服务超出 API 速率限制所致，并叠加了一个缓存错误，该错误使受速率限制的状态在实际速率限制窗口结束后仍然持续存在，从而导致反复中断。

我们的团队在 15 分钟内检测到该问题，并立即开始调查。我们通过功能开关禁用了有问题的速率限制缓存机制，并更新服务以使用按安装划分的凭据进行 API 调用，从而确保速率限制被正确限定在单个安装范围内，进而缓解了此次事件。服务已于 UTC 时间 20:36 完全恢复。事件期间被延迟的作业已进入队列，并在服务恢复后得到处理。

此后，我们已添加自动化监控和告警，以主动检测这种故障模式；部署了修复措施，通过改进缓存来减少不必要的 API 流量；并且正在继续推进工作，以进一步隔离不同客户端类型之间的速率限制范围，从而防止未来出现类似问题。

4 月 13 日 19:56 UTC（持续 39 分钟）

2026 年 4 月 13 日 18:53 UTC 至 20:30 UTC 期间，GitHub Pages 服务出现错误率升高。平均错误率为 10.58%，峰值达到该服务请求量的 12.77%，导致约 1750 万次请求失败并返回 HTTP 500 错误。

此次事件是由于一个自动化 DNS 管理工具错误地删除了 GitHub Pages 后端存储主机的一条 DNS 记录：其上游数据源间歇性未能返回该记录，导致该工具将其视为过期记录并将其移除。随着该记录的缓存副本在我们的系统中陆续过期，GitHub Pages 服务器不再能够访问受影响的存储主机，从而导致部分请求出错。

问题确认后，我们的团队迅速追踪到缺失的 DNS 记录并重新创建了它。服务于 20:30 UTC 恢复正常，该事件于 20:35 UTC 完全解决。我们认识到，检测所花时间比我们期望的更长——约 53 分钟——这是由于错误率逐步上升，以及我们对此类故障的告警存在缺口。

我们正在进行三项关键改进，以防止未来出现类似问题。我们正在 GitHub Pages 前端实现可容忍可用区故障的路由，使无法解析的后端主机触发故障转移到健康主机，而不是返回错误；添加保护措施，防止自动删除由其他系统拥有的 DNS 记录；并改进 GitHub Pages 服务路径中 DNS 解析失败的日志记录和告警。

4 月 16 日 15:06 UTC（持续 3 小时 22 分钟）

2026 年 4 月 16 日 09:30 UTC 至 17:15 UTC 期间，用户在尝试通过 VS Code 编辑器连接到 GitHub Codespaces 时遇到失败。在此期间，约 40% 的 codespace 启动操作失败。通过 SSH 连接的用户未受影响。

该问题是由上游服务故障导致的，这些故障使得在 codespace 启动期间无法获取 VS Code Server。通过实施一种变通方案，在主端点性能降级时使用备用下载路径，从而缓解了影响。同时，我们与上游依赖团队协调，以解决下载失败的根本原因。

我们正在改进回退机制，以降低未来类似上游故障的影响，并简化流程，以便将来更快部署类似变更。

4 月 20 日 13:28 UTC（持续 15 小时 36 分钟）

2026 年 4 月 20 日 10:28 UTC 至 15:04 UTC 期间，GitHub 的代码扫描默认设置、代码质量和项目看板服务出现降级。受影响项目看板的修复还额外持续到 4 月 21 日 05:04 UTC。

在此期间，新打开的拉取请求未触发代码扫描默认设置和代码质量分析。此外，新创建的问题未显示在项目看板上。

原因是一个序列化错误，该错误阻止了代码扫描、代码质量分析和项目看板更新的正常触发。

我们在约 40 分钟内发现了该问题，并通过部署修复措施缓解了问题，恢复了代码扫描和代码质量的事件发布。对于项目看板，我们部署了额外的代码变更以更新事件消费者，随后对受影响的项目条目进行了重新索引。

我们正在通过加强架构验证并改进对关键主题发布下降情况的监控来防止问题再次发生。此外，我们正在审查系统的其他部分，以确保其他地方不存在类似限制。

4 月 22 日 15:35 UTC（持续 3 小时 43 分钟）

2026 年 4 月 22 日 15:16 UTC 至 19:18 UTC 期间，用户在 github.com 上与 Copilot Chat 和 Copilot Cloud Agent 交互时遇到错误。在此期间，用户无法使用 Copilot Chat 或 Copilot Cloud Agent。Copilot Memory（预览版）在此期间无法用于 Copilot agent 会话。

该问题是由一次基础设施配置变更引起的，该变更导致我们与数据库的连接出现问题。团队确定了原因，并恢复了与数据库的连接。github.com 的 Copilot Chat 和 Cloud Agent 已于 18:16 UTC 恢复。其余区域部署逐步恢复，并于 19:18 UTC 完全解决。

我们已采取措施，防止未来类似的基础设施变更导致此类数据库操作问题。

4 月 23 日 16:12 UTC（持续 1 小时 18 分钟）

2026年4月23日16:03至17:30（UTC）期间，用户在 GitHub Copilot、Webhooks、Git Operations、GitHub Actions、Migrations 和 Deployments 中遇到错误率升高和性能下降。 在1小时27分钟的影响窗口期间，约5–7%的总体流量受到影响。对于 Copilot，约7%的 AI 模型请求失败，约10%的 Copilot 云代理会话受到影响，约9%的 Copilot Insights 仪表板请求返回错误。对于 Webhooks，峰值时约0.35%的 API 请求返回错误，最多10%的流量出现延迟升高（>3秒）。Git Operations 在事件持续期间的平均错误率为1.25%，峰值为2.07%。GitHub Actions 的工作流运行状态更新出现了最高约8秒的延迟。对于 Migrations，0.88%的活动仓库迁移失败，79%的迁移持续时间升高。Deployments 暂时被阻断

我们位于一个数据中心的 DNS 基础设施进入降级状态，并开始间歇性地无法解析服务地址。这造成了级联影响：依赖名称解析来与内部 API、外部提供商和存储系统通信的服务同时都出现了错误。

根本原因是近期引入的一种流量均衡机制，该机制此前已逐步推出以支持我们的增长。在一种特定的负载模式下，该机制导致 DNS 解析器开始出现故障。现有的 DNS 缓存提供了部分保护。具有近期缓存条目的服务继续正常运行，这也是整体影响被限制在约 5–7% 流量、而非发生完全中断的原因。

在初始配置回滚未能解决问题后，我们重启了受影响的 DNS 基础设施。服务在数分钟内开始恢复，并于 UTC 时间 17:30 全部恢复正常。没有数据丢失；所有代码仓库、数据库和工作流数据均未受影响。

为防止未来发生此类事件，我们正在提升 DNS 基础设施的韧性，以防止单一数据中心故障在服务之间级联传播；通过专用环境对基础设施变更进行更安全的发布和验证，使其能够在类似生产环境的流量下进行测试；投资建设更快速的自动化检测与恢复能力，为 DNS 解析故障引入自愈机制；并通过审查服务对共享基础设施组件的依赖来降低影响范围。

4 月 27 日 16:31 UTC（持续 6 小时 15 分钟）

2026 年 4 月 27 日 16:15 UTC 至 22:46 UTC 期间，由于部署在我们搜索基础设施前端的负载均衡层达到饱和，GitHub 搜索服务出现连接性下降。这导致依赖我们搜索数据的服务出现间歇性故障，包括 Issues、Pull Requests、Projects、Repositories、Actions、Package Registry 和 Dependabot Alerts。影响因搜索目标而异，在 16:15 UTC 至 18:00 UTC 期间，部分服务多达 65% 的搜索请求超时或返回错误。

我们通过持续监控检测到搜索结果下降，并于 16:21 UTC 宣布发生事件。我们在 21:33 UTC 将该事件标记为已缓解，并持续监控系统，直至 22:46 UTC 宣布该事件已解决。

此次饱和是由大量匿名分布式抓取流量涌入造成的，这些流量经过设计以避开我们的公共 API 速率限制。该抓取流量占当天搜索总流量的 30%，但集中在四小时内。流量来自超过 600,000 个唯一 IP 地址，所有请求中都带有匹配的行为者信息。我们现有的监控未将增加的抓取活动归类为风险，事件的这一维度是在缓解过程中才被发现的。

为缓解这一情况，我们立即着手减轻负载均衡器的压力，同时扩展负载均衡层、阻断异常流量，并对负载均衡器进行调优，以彻底解决此次事件。

展望未来，我们不仅已经扩展了负载均衡器层，还进行了优化，以改进连接处理和复用，降低此类饱和事件再次发生的可能性。我们还在平台内新增了监控和控制措施，使我们能够限制匿名流量，从而减轻对注册用户的影响。我们将继续加强对这类大规模自动化滥用行为的防御。

请关注我们的状态页面，以获取状态变更和事件后回顾的实时更新。若要了解更多我们正在开展的工作，请查看 GitHub Blog 上的工程板块。

撰写者

正文：Jakub Oleksy

正文：@jakuboleksy