与拉取请求有关的事件
2026年9月20日,UTC时间21:46至22:24期间,Pull Requests服务出现降级,拉取请求合并和测试合并提交创建延迟,高峰时延迟约达四分钟。合并提交是延迟而非丢失。由于某些Actions工作流运行仅在拉取请求的合并提交创建后才开始,因此部分针对拉取请求事件的工作流运行也出现了延迟。<br /><br />这是由于一个异常庞大的仓库执行例行仓库维护作业,几乎耗尽了一台Git存储服务器的全部内存,导致该服务器无法为创建合并提交所需的Git操作提供服务。<br /><br />我们通过在UTC时间22:18将该受影响服务器从服务中移除来缓解了此事件,此后排队的合并提交在六分钟内完成创建。<br /><br />我们已对单个仓库维护作业可消耗的内存设置了上限,以确保单个仓库不会耗尽服务器资源,并且我们改进了对存储服务器健康状况的监控和告警,以减少未来类似问题的检测和缓解时间。
原文On September 20, 2026, between 21:46 and 22:24 UTC the Pull Requests service was degraded and pull request merge and test-merge commits were created late, with delays reaching approximately four minutes at peak. Merge commits were delayed rather than lost. Because some Actions workflow runs start only after a pull request's merge commit is created, a subset of workflow runs for pull request events were also delayed. <br /><br />This was due to a routine repository maintenance job for an unusually large repository consuming nearly all of the memory on a single Git storage server, which left that server unable to serve the Git operations used to create merge commits. <br /><br />We mitigated the incident by removing the affected server from service at 22:18 UTC, after which the queued merge commits were created within six minutes. <br /><br />We have capped the memory a single repository maintenance job may consume so that one repository cannot exhaust a server, and we have improved monitoring and alerting on storage server health to reduce our time to detection and mitigation of issues like this one in the future.
一个 git 文件服务器问题导致创建某些合并提交时出现短暂延迟——我们已隔离底层服务器,并已观察到恢复。
原文A git fileserver issue caused a brief delay in creating some merge commits - we've isolated the underlying server and already observed recovery.
影响Pull Requests的服务降级问题已得到缓解。我们正在持续监控以确保稳定性。
原文The degradation affecting Pull Requests has been mitigated. We are monitoring to ensure stability.
我们正在调查关于拉取请求性能下降的报告。
原文We are investigating reports of degraded performance for Pull Requests
关于这些数据
GitHub的故障事件数据从哪来?
全部来自GitHub 官方状态页的公开接口,由本站每 5 分钟同步一次,保留最近 90 天。事件标题、时间、影响级别与更新记录均为官方原文,本站不做改写;点详情页底部的链接可回到厂商原始记录核对。
顶部的组件状态条怎么看?
每一格是一天,绿色表示GitHub 官方状态页当天未记录异常,黄色表示部分降级,红色表示当天有较大故障,灰色表示该组件当时还没有数据。右侧的可用率是官方口径的 90 天统计,与状态总览页显示的是同一份数据。
为什么有的服务查不到历史?
本页只收录对外提供官方状态页的服务。没有公开状态页的厂商(多数国产大模型属于此类)无法取得可信数据,本站不做自建拨测去猜,因此也不会出现在状态总览里。
持续时长怎么算?
按官方标注的开始时间到恢复时间计算;尚未恢复的事件按「至今」计算并标为进行中。跨天的事件在状态条上会覆盖它经过的每一天。
完整的服务清单与实时状态见状态总览。