GitHub 中断历史

1. 2026年10月27日 UTC 20:21resolved

   在协调世界时6:55至08:01于10:27,客户遭遇了API和git请求的故障率提高,GitHub Apps的服务器到服务器代号(不包括动作代号)认证. 在这个窗口中,经认证的git操作错误地将平均1.24%的请求(2.6x)和2.49%的请求(5.3x)退回404个。 GitHub将7个表格迁移到IAD和Azure Central US数据中心的两个MySQL集群之间, 一个受影响的表格存储了GitHub App服务器到服务器的安装记录(不包括动作). 最近几个月我们成功完成了其中的几次迁移,没有显著的客户影响. 然而,在这种情况下,迁移与安装记录表中的预定清理工作同时进行,从协调世界时0444-0617中删除了约5900万个记录. 因此,在迁移中使用的gh-ost工具出现了集群间复制延迟(高峰时最多1小时). 在协调世界时6:55,我们开始将目标表的读取功能转换到新的MySQL集群,在协调世界时07:21,100%的读取功能切换功能. 在整个阅读切换过程中,客户撞击开始,但没有被检测出,并持续到协调世界时08:01完成写入切换. 我们正在更新我们的程序和自动化,以防止这一事件的再起,包括在这些迁移之前使重叠的清理工作无法进行,并在复制延误严重时阻止阅读的剪接.

自动翻译自官方事件更新。

1. 2026年10月26日 UTC 18:48investigating

   我们正在为API的请求、行动、问题和拉动请求调查有关业绩退化的报告

2. 2026年10月26日 UTC 18:50monitoring

   退化已经得到缓解。 我们正在监测以确保稳定.

3. 2026年10月26日 UTC 18:54monitoring

   我们看到影响REST API请求的延迟度提高,包括检查,以及一些动作、问题、拉请求和GraphQL功能。 一些请求可能进展缓慢或超时,通知从协调世界时17:59 - 18:40延迟. 我们缓解了这一问题,所有服务都已恢复.

4. 2026年10月26日 UTC 18:57resolved

   这一事件已经得到解决。 感谢你在处理这一问题时的耐心和理解。 详细的根源分析一旦完成,将立即共享.

自动翻译自官方事件更新。

1. 2026年10月23日 UTC 23:41investigating

   我们正在调查关于副驾驶AI模型供应商业绩下降的报告

2. 2026年10月23日 UTC 23:42investigating

   我们正经历着副驾驶产品和IDE表面的Grok 4.6和Grok 4.7模型的可用性下降。 这是由于上游模式提供者的问题。 在我们与他们合作解决问题的同时,我们建议选择另一种模式或选择"Auto"继续使用副驾驶.

3. 2026年10月24日 UTC 00:23monitoring

   影响副驾驶AI模型供应商的退化已经得到缓解。 我们正在监测以确保稳定.

4. 2026年10月24日 UTC 00:23resolved

   在协调世界时2026年10月27日23:28至00:23之间,GitHub副驾驶经历了退化,影响了Grok 4.6和Grok 4.7型号. 用户在使用这些模型时遇到了较高的出错率. 退化是由于一个上游模式提供者的问题造成的。 GitHub工程师通过自动监控和与供应商的协调来发现这个问题. 我们的自动模型预警系统在事故中启动了对受影响模型的产地警告。 在供应商实施缓解后,服务恢复正常.

自动翻译自官方事件更新。

1. 2026年10月23日 UTC 14:58investigating

   我们正在调查一些GitHub服务公司受影响业绩的报告.

2. 2026年10月23日 UTC 15:00investigating

   我们正调查一些Deptabot警报的延迟, 警报处理已备份 。 我们将会分享更多信息.

3. 2026年10月23日 UTC 15:39investigating

   我们正在扩大警示处理能力, 我们将继续监控.

4. 2026年10月23日 UTC 16:11investigating

   我们正继续调查一些Deptabot警报的延迟, 警报处理工作仍然得到备份,额外的处理能力正在逐步扩大,以帮助减少积压。 将分享更多最新消息.

5. 2026年10月23日 UTC 16:43investigating

   我们正继续调查一些Deptabot警报的延迟, 警报处理工作仍然得到备份,额外的处理能力正在逐步扩大,以帮助减少积压。 我们正监测进展.

6. 2026年10月23日 UTC 17:27investigating

   在储存库更新后,一些依赖性警报继续被推迟关闭。 我们继续调查,努力恢复正常处理.

7. 2026年10月23日 UTC 18:36monitoring

   退化已经得到缓解。 我们正在监测以确保稳定.

8. 2026年10月23日 UTC 18:51resolved

   我们发现,一个咨询出版物驱动的粉丝出炉在存储器上是压倒性的依赖性警报处理,其方法是用自己的事件饱和排队,推迟处理与存储器推力相关的事件。 我们现在隔离了这个粉丝 并施放油门 因此它以固定的速度运行 并且不能拖延其他事件 这种补救成功地防止了新的扇出过程影响用户.

自动翻译自官方事件更新。

1. 2026年10月23日 UTC 07:29investigating

   我们正在调查关于行动业绩下降的报告

2. 2026年10月23日 UTC 07:31investigating

   我们看到,从协调世界时07:07起,GitHub内部报告的行动工作流程结果出现延误。 已经看到复苏,但我们的小组正在继续调查和监测业绩.

3. 2026年10月23日 UTC 07:53monitoring

   影响行动的退化已经得到缓解。 我们正在监测以确保稳定.

4. 2026年10月23日 UTC 07:56monitoring

   从协调世界时07:27起,行动结果再次在正常的SLO范围内交付. 感谢你在行动成果交付延迟期间的这种耐心。 我们的团队继续监测系统健康,并探索完善措施,以减少今后对客户的影响.

5. 2026年10月23日 UTC 08:05resolved

   这一事件已经得到解决。 感谢你在处理这一问题时的耐心和理解。 详细的根源分析一旦完成,将立即共享.

自动翻译自官方事件更新。

1. 2026年10月22日 UTC 15:28investigating

   我们正在调查关于 " 行动、问题和拉动请求 " 退化业绩的报告

2. 2026年10月22日 UTC 15:33investigating

   一些用户可能会在github.com上遇到间歇性错误加载问题,拉出请求和搜索结果. 我们正在调查和努力恢复正常服务.

3. 2026年10月22日 UTC 16:08investigating

   一些用户在github.com上继续经历间歇性错误加载问题,拉出请求和搜索结果. 我们正在调查和评价各种缓解方案,以恢复正常服务.

4. 2026年10月22日 UTC 16:26investigating

   API请求的绩效正在下降。 我们正在继续调查.

5. 2026年10月22日 UTC 16:28investigating

   套件的性能正在退化。 我们正在继续调查.

6. 2026年10月22日 UTC 16:35investigating

   API 请求正常运行.

7. 2026年10月22日 UTC 16:41investigating

   一些用户在github.com上继续体验错误加载问题,Pull Request,软件包列表和搜索结果. 我们正在通过多重缓解努力继续调查.

8. 2026年10月22日 UTC 17:16investigating

   增加容量后,我们看到恢复,错误减少。 一些用户可能在github.com上仍然会遇到错误加载问题,拉出请求和搜索结果. 我们继续努力争取全面恢复,监测稳定.

9. 2026年10月22日 UTC 17:41investigating

   行动、问题、软件包和拉动请求正常运行.

10. 2026年10月22日 UTC 17:43investigating

    受灾部门恢复了 GitHub Projects仍在恢复中,因为排队更新正在处理中,我们继续监视稳定性.

11. 2026年10月22日 UTC 18:26investigating

    其他受影响的服务已经恢复。 我们继续调查GitHub Projects 核实正常运行已经恢复.

12. 2026年10月22日 UTC 19:04investigating

    GitHub Projects中的一些更新仍然被延迟. 我们正在继续缓解工作和监测.

13. 2026年10月22日 UTC 19:56investigating

    一些GitHub Projects的更新与问题更改和合并拉动请求相关,但仍被延迟. 我们正在调查剩下的延误,并努力恢复正常的处理.

14. 2026年10月22日 UTC 20:46investigating

    一些GitHub项目更新,包括新增加的项目、问题变更和拉动请求,仍然被推迟。 已发现更新处理中断,并正在评估缓解措施以恢复正常运行.

15. 2026年10月22日 UTC 22:07investigating

    一些GitHub项目更新,包括新增加的项目和问题更改以及拉动请求,仍然被推迟. 我们看到了一些复苏,并正在努力增加加快复苏的能力.

16. 2026年10月22日 UTC 23:48investigating

    GitHub Projects更新处理有所改进,但新添加的项目仍可能比预期的出现时间要长. 我们正在继续研究剩下的拖延问题,并监测恢复情况.

17. 2026年10月23日 UTC 00:55monitoring

    退化已经得到缓解。 我们正在监测以确保稳定.

18. 2026年10月23日 UTC 02:30resolved

    这一事件已经得到解决。 感谢你在处理这一问题时的耐心和理解。 详细的根源分析一旦完成,将立即共享.

自动翻译自官方事件更新。

1. 2026年10月22日 UTC 14:18investigating

   我们正在调查关于行动业绩下降的报告

2. 2026年10月22日 UTC 14:19investigating

   GitHub Action 工作流程和步骤结果的处理出现延误.

3. 2026年10月22日 UTC 14:35investigating

   仓库更新处理恢复. 我们继续研究影响GitHub动作工作流程和步骤结果的拖延问题。 我们将会分享最新进展.

4. 2026年10月22日 UTC 15:06investigating

   库藏更新处理已恢复正常。 随着我们扩大处理能力,影响GitHub Action工作流程和步骤结果的拖延正在继续被清除;所剩的积压预计将需要约20分钟的时间来排出.

5. 2026年10月22日 UTC 15:17monitoring

   影响行动的退化已经得到缓解。 我们正在监测以确保稳定.

6. 2026年10月22日 UTC 15:18monitoring

   GitHub 动作工作流程和步骤结果处理已恢复。 仓库更新处理也已经恢复正常.

7. 2026年10月22日 UTC 15:18resolved

   这一事件已经得到解决。 感谢你在处理这一问题时的耐心和理解。 详细的根源分析一旦完成,将立即共享.

自动翻译自官方事件更新。

1. 2026年10月21日 UTC 14:52investigating

   我们正在调查关于行动、拉请求和网络呼喊的退化业绩的报告

2. 2026年10月21日 UTC 15:15investigating

   行动的业绩正在退化。 我们正在继续调查.

3. 2026年10月21日 UTC 15:36investigating

   我们正在调查延迟 影响拉动请求更新 和网络快递。 我们活动流媒体平台的负荷增加,有助于热点。 我们正在将交通从受影响地区移出,并增加加工能力;在这些减缓措施生效的同时,影响仍在继续.

4. 2026年10月21日 UTC 15:58investigating

   我们继续看到拖延影响拉动请求的更新、网络浏览交付和审计记录活动。 事件流出平台呈现复苏迹象,我们正在监测影响的持续情况.

5. 2026年10月21日 UTC 16:17investigating

   审计日志事件和行动工作流程更新继续被推迟。 正在恢复事件处理和工作, 我们正监测复苏情况.

6. 2026年10月21日 UTC 16:25investigating

   审计日志活动被延迟了多达100分钟,行动工作流程状态更新继续被长时间拖延. 正在恢复事件处理和工作, 我们正监测复苏情况.

7. 2026年10月21日 UTC 16:33investigating

   拉出请求正常运行.

8. 2026年10月21日 UTC 16:34investigating

   审计日志活动继续被拖延到110分钟。 调用请求更新已恢复 。 行动正在恢复,用户不应再体验行动的影响。 Webhook的交货在我们处理积压时继续恢复。 我们正在监测复原情况,并将在了解更多情况后分享进一步的最新情况.

9. 2026年10月21日 UTC 16:57investigating

   动作和Webhooks正常运行.

10. 2026年10月21日 UTC 16:59investigating

    行动与网络邮递已恢复。 审计日志活动仍然被延迟了约100分钟. 我们正在处理积压工作,全面恢复需要一些时间。 随着复苏的继续,我们将分享更多的最新情况.

11. 2026年10月21日 UTC 17:09investigating

    调取请求更新, 动作, 和网络快递已恢复 。 审计日志事件正在恢复,拖延现象正在减少,但我们预计剩余的积压工作需要大约两到三个小时才能清理。 我们正监测复苏情况.

12. 2026年10月21日 UTC 18:18investigating

    审计日志活动正在恢复,随着剩余积压的处理,延误时间现在不到90分钟。 并监测复苏情况。 随后将进一步提供最新情况.

13. 2026年10月21日 UTC 18:52investigating

    审计日志活动继续恢复,目前拖延时间不到70分钟。 我们已运用缓解措施来加速恢复, 调取请求的更新、 动作、 和网络快递仍可回收 。 我们正在监测进展情况,并将进一步介绍最新情况.

14. 2026年10月21日 UTC 19:22investigating

    调取请求更新, 动作, 和网络快递已恢复 。 审计日志的延迟时间现在不到40分钟,在健康的门槛之内,随着剩余积压的处理继续减少.

15. 2026年10月21日 UTC 19:22resolved

    这一事件已经得到解决。 感谢你在处理这一问题时的耐心和理解。 详细的根源分析一旦完成,将立即共享.

自动翻译自官方事件更新。

1. 2026年10月19日 UTC 15:49investigating

   我们正在调查关于 行动与页面退化的绩效报告

2. 2026年10月19日 UTC 15:50investigating

   Webhooks的性能正在下降。 我们正在继续调查.

3. 2026年10月19日 UTC 15:56investigating

   GitHub Actions、GitHub Pages 和 Webhooks 等。 客户在工作流程处理、网站建设和网络浏览交付方面可能遇到延误.

4. 2026年10月19日 UTC 16:30investigating

   我们正看到缓解后复苏, GitHub Action 工作流程状态更新, GitHub Pages 部署, 以及检查和工作流程中由 Action 运行生成的 Webhook 事件, 客户仍然可能遇到延误 .

5. 2026年10月19日 UTC 16:56monitoring

   动作、页面和网页正常运行.

6. 2026年10月19日 UTC 16:56resolved

   2026年10月19日,在协调世界时15:24至16:52之间,GitHub Actions,GitHub Pages,和由Actions所生成的webhooks被退化. 在GitHub.com和代码搜索上的直播更新也在这段时间退化了. 没有丢失数据 。 影响 工作流程更新、日志和检查被推迟。 - 5.13%的GitHub托管跑道员的工作延迟开始,0.02%的工作流程运行失败。 - 在头30分钟,8.47%的Actions jobs RESST API请求返回了错误。 动作运行生成的页面部署和网点被延迟 。 一个存储日志和运行状态的内部Action服务丢失了与它在一个云区的一些缓存服务器的连接,并立即从每个服务器中重新测试. 由此而来的新连接激增,使我们的数据中心与该区域之间的共享网络链接超负荷,这也干扰了使用同一链接的其他服务。 我们通过将Actions服务从受影响的缓存服务器上移出并减少链接上其他服务的连接来缓解了这一事件. 然后我们处理推迟的行动工作。 我们正在继续调查最初中断连接的原因。 我们已经开始推出限制程序, 以限制这项服务能有多快打开新连接, 从那时起,我们充分执行了它,并取消了服务同时进行的连接尝试。 我们正在将这些限制扩展到其他动作服务,在复试中增加后退,限制一个单一服务可以使用多少共享的网络容量,并改进警报,以便我们能够更快地找到连接源.

自动翻译自官方事件更新。

1. 2026年10月15日 UTC 18:31investigating

   我们正在调查一些GitHub服务公司受影响业绩的报告.

2. 2026年10月15日 UTC 18:34investigating

   当用户启动自动化时, CCA 自动化会遇到延迟

3. 2026年10月15日 UTC 18:53monitoring

   退化已经得到缓解。 我们正在监测以确保稳定.

4. 2026年10月15日 UTC 18:56resolved

   我们怀疑,当用户开始自动化时,共同国家评估自动化系统出现延误,但进一步调查发现,共同国家评估自动化系统没有延误或影响.

自动翻译自官方事件更新。

1. 2026年10月14日 UTC 00:12resolved

   UTC10月13日20:42左右,基础设施故障导致GitHub Actions出现延迟显示工作流程运行日志. 没有丢失日志,这个问题现已得到解决,日志处理工作陷入了困境。 生成日志的实际工作流程没有受到影响和正常运行,也没有出现运行延误或检查延误.

自动翻译自官方事件更新。

1. 2026年10月12日 UTC 12:21investigating

   我们正在调查关于 " 行动、问题和拉动请求 " 退化业绩的报告

2. 2026年10月12日 UTC 12:33investigating

   用户可能遇到装入动作标签UI的问题,与Checks API互动,排队新动作运行,创建并更新问题,以及请求PR审查,包括通过REST和GraphQL API.

3. 2026年10月12日 UTC 12:57investigating

   我们正在减缓影响,并正在监测恢复情况。 用户还可能会遇到延迟的网络通知,因为我们可以缓解.

4. 2026年10月12日 UTC 13:02investigating

   拉出请求正常运行.

5. 2026年10月12日 UTC 13:38investigating

   我们最初的缓解措施没有完全成功,用户仍然可能遇到延误,行动、问题和项目出现错误,通知被推迟。 我们继续调查根源,努力进一步缓解.

6. 2026年10月12日 UTC 14:35investigating

   影响问题的退化已经得到缓解。 我们正在监测以确保稳定.

7. 2026年10月12日 UTC 14:36investigating

   影响行动的退化已经得到缓解。 我们正在监测以确保稳定.

8. 2026年10月12日 UTC 14:37investigating

   我们通过行动、问题和项目减轻了这些问题,并正在通过通知缓解拖延.

9. 2026年10月12日 UTC 15:19investigating

   我们已经成功地对通知适用了减缓措施,通知已经恢复,但随着我们处理积压的工作,将继续被拖延.

10. 2026年10月12日 UTC 15:50investigating

    通知已经恢复,但随着我们处理积压的工作,将继续被拖延.

11. 2026年10月12日 UTC 17:34investigating

    在我们处理积压的通知时,网络和电子邮件通知继续被拖延.

12. 2026年10月12日 UTC 19:28investigating

    网络和电子邮件通知将再拖延一个小时,因为我们即将完成积压的通知.

13. 2026年10月12日 UTC 20:16resolved

    2026年10月12日 UTC上午11:51,GitHub在多个应用页面上收到了500个更高的回复. 这造成问题和拉动请求以及项目和行动方面的失败。 客户在网络收件箱和电子邮件中也收到延迟通知。 UTC10月12日12:41减轻了对问题,拉出请求,项目和行动的直接影响. 在协调世界时15:27分,向网络收件箱和电子邮件发送的通知正在恢复,并在协调世界时20:16分全面减少。 事件是由我们通知发送管道中的一个潜在条件引发的,这一条件使我们的破损数据库复制品上出现了大量昂贵的查询。 这削弱了满足问题、拉动请求、项目和行动请求的现有数据库能力。 提供昂贵的查询。 我们还正在提高数据库层的复原力,以降低类似事件的可能性和影响.

自动翻译自官方事件更新。

1. 2026年10月7日 UTC 17:17investigating

   我们正在调查关于 " 行动 " 、 " 巨人行动 " 、 " 问题 " 和 " 要求 " 的退化业绩的报告

2. 2026年10月7日 UTC 17:25investigating

   我们看到,从协调世界时16:52到协调世界时17:01,GitHub服务受到广泛影响,目前正在调查根源。 所有系统都恢复了 此事件从更早时的https://www.githubstatus.com/incicents/djlmxz2zd0j7再现. 持久的缓解工作正在进行。 我们将在30分钟后再次提供最新情况.

3. 2026年10月7日 UTC 17:27monitoring

   退化已经得到缓解。 我们正在监测以确保稳定.

4. 2026年10月7日 UTC 18:00monitoring

   所有系统都恢复了 我们采取了缓解措施,并预计不会再发生这种情况.

5. 2026年10月7日 UTC 18:04resolved

   2026年10月7日,从协调世界时16:52到17:01,GitHub经历了当天早些时候的写作停用. 两种停电都有同样的根源。 请参看关于这两起事件、其影响和预防措施的综合摘要: https://www.githubstatus.com/incidents/djlmxz2zd0j7 互联网档案馆的存檔,存档日期2014-12-2

自动翻译自官方事件更新。

1. 2026年10月7日 UTC 15:14investigating

   我们正在调查关于 " 行动 " 、 " Git行动 " 和 " 拉出请求 " 的可用性下降的报告

2. 2026年10月7日 UTC 15:15investigating

   问题正在发生业绩下降。 我们正在继续调查.

3. 2026年10月7日 UTC 15:16investigating

   网络用户的可用性正在下降。 我们正在继续调查.

4. 2026年10月7日 UTC 15:24investigating

   在协调世界时15:06至协调世界时15:16之间,我们看到了GitHub服务的广泛影响,并正在调查其根源。 我们看到所有系统都恢复了,不久将提供另一个最新情况.

5. 2026年10月7日 UTC 15:25investigating

   拉动请求的性能正在下降。 我们正在继续调查.

6. 2026年10月7日 UTC 15:27investigating

   Git 操作正常运行 .

7. 2026年10月7日 UTC 15:27investigating

   Webhooks的性能正在下降。 我们正在继续调查.

8. 2026年10月7日 UTC 15:31investigating

   影响拉力请求的退化已经得到缓解。 我们正在监测以确保稳定.

9. 2026年10月7日 UTC 15:32investigating

   行动正常.

10. 2026年10月7日 UTC 15:35investigating

    Git业务公司业绩下降。 我们正在继续调查.

11. 2026年10月7日 UTC 15:41investigating

    我们正在观察所有系统的部分恢复情况。 我们正在继续监测和调查破坏的根源.

12. 2026年10月7日 UTC 15:47investigating

    影响问题的退化已经得到缓解。 我们正在监测以确保稳定.

13. 2026年10月7日 UTC 15:49investigating

    影响Git业务和Webhooks的退化已经得到缓解. 我们正在监测以确保稳定.

14. 2026年10月7日 UTC 15:56monitoring

    退化已经得到缓解。 我们正在监测以确保稳定.

15. 2026年10月7日 UTC 15:58monitoring

    所有系统,包括Git业务、Pull Experts和Action系统,都在全面恢复。 我们正在继续调查协调世界时15:06至协调世界时15:16之间中断的根本原因,并将很快分享另一个最新情况.

16. 2026年10月7日 UTC 16:23monitoring

    Git Operation, Pull Arequest and Actions 完全恢复和稳定. 已查明了根源,并正在采取缓解措施来防止再发.

17. 2026年10月7日 UTC 16:25resolved

    2026年10月7日,GitHub因同样原因两次停止了写作操作,总计约19分钟. 第一次从协调世界时15:06跑到15:16(约10分钟),第二次从协调世界时16:52跑到17:01(约9分钟). 在两个窗口中,保存或更改数据的行动在 Git 操作中都失败了,拖取请求,发行, GitHub Actions, API, webhooks, sign-in和认证, GitHub Apps 和 OAuth, 代码扫描, Codespaces, 和 Copilot. 阅读数据基本上没有受到影响。 在第一次断电中,5.6%的网络和API请求失败了,最高达到8.9%,超过1.2万个组织看到请求失败. 高达26%的Git认证请求失败了,17%的Action工作流程运行失败了基础设施出错. 在第二次停电时,6.2%的网络和API请求失败,达到9.3%,超过1.1万个组织受到影响. 高达25%的Git认证请求失败,19%的Action工作流程运行失败. 没有数据库出现数据丢失,在恢复成功后,业务进行了再测试。 GitHub依赖于一个内部服务,可以跟踪数据库服务器应接收哪些新数据和更新数据. 在更换运行此服务的机器作为常规维护的一部分的同时,其中一款新机器开始使用已过时的其记录副本,这些记录仍列出我们已经退休的数据库服务器. 当这个节点上线时,它用已过时的记录错误地修改了路由配置,将路由写入请求转到已不存在的数据库服务器. 每一次停产都结束了, 我们的固定机器之一 有正确的配置 成为了法定人数的领导者 并发送正确的配置。 第一次停机后,确定新机为源,并暂停了自动维护,以阻止它再次成为领导. UTC下午16:52分,一项不尊重暂停状态的自动维修任务又将它重新放回了主管位置,停电再次出事. 在协调世界时17:02,我们关闭了这台机器,并从此拆除了它,现在的自动化尊重了暂停,由于更新了我们的傀儡基础设施,这是一个新的倒退。 为了防止重现,我们正在将已退役的数据库服务器从服务记录中清除,然后才添加出任何新的机器,而且我们正在将新机器保留下来,直到其记录得到检查为止。 我们还在改变我们的系统,拒绝指向不存在的服务器的配置,而是继续使用最后已知的好设置。 最后,我们给响应者一个更快的方法 让一个行为不检的机器退出服务, 并加入警报, 这样的变化在几秒钟内就会发现。 我们将在我们每月的可用情况报告中更详细地叙述这些事件,并介绍我们为防止今后出现此类问题而正在开展的修复工作的现状.

自动翻译自官方事件更新。

1. 2026年10月6日 UTC 19:57investigating

   我们正在调查关于Pull Request和Webhooks 业绩下降的报告

2. 2026年10月6日 UTC 20:04investigating

   Webhooks正常运行.

3. 2026年10月6日 UTC 20:12investigating

   拉出请求正常运行.

4. 2026年10月6日 UTC 20:22investigating

   一些服务,包括问题、牵引请求和网络呼号,已经短暂地退化,但现在已经恢复。 企业迁移被暂停,同时我们验证原因和缓解措施.

5. 2026年10月6日 UTC 20:26monitoring

   退化已经得到缓解。 我们正在监测以确保稳定.

6. 2026年10月6日 UTC 20:57investigating

   所有服务正常运行,企业迁移除外,企业迁移仍然被暂停. 他们很快就会恢复.

7. 2026年10月6日 UTC 21:29investigating

   我们正在为减缓危机而努力,这将使我们能够恢复加工企业迁移.

8. 2026年10月6日 UTC 22:40investigating

   我们正在采取缓解措施,并计划不久后恢复移徙

9. 2026年10月6日 UTC 23:40resolved

   2026年10月6日,从协调世界时19:44到19:50,GitHub遭遇了一次服务中断,高误差率达到顶峰,占所有请求的1.30%,总共约116万个失败请求. 这影响到整个GitHub的12项服务,包括Pull Request、Webhooks、Repos、OAuth、Git over SSH、Codespaces和Gists。 事件由GitHub Entertainment Introductioner(GEI)公司(GEI)进行多次长时间查询而引发,使数据库连接池饱和. 在协调世界时19:50左右,移民的电话中断后,出现了复苏;GEI移民在协调世界时23:32,代码被合并后重新启用. 我们完成了详细的根由审查并正在执行改进的数据库-保健保障措施。 我们将继续审查和增加额外的保障措施,以防止今后再次发生.

自动翻译自官方事件更新。

1. 2026年10月5日 UTC 23:47investigating

   我们正在调查一些GitHub服务公司受影响业绩的报告.

2. 2026年10月6日 UTC 00:05investigating

   用户可能会遇到访问组织和企业账单和许可证页的问题。 我们正在部署缓解和监测恢复工作.

3. 2026年10月6日 UTC 01:32resolved

   2026年10月5日,从协调世界时23:05到协调世界时00:11,10月6日,一些用户在访问组织和企业计费,许可,设置页面时遇到缓慢的页面负荷,超时,以及出错. 平均来说,错误率为1.9%,最高达到13.8%对授权这些页面的服务的要求。 造成这种情况的原因是联网失败,这中断了我们一个虚拟数据中心区域与云托管区域数据库服务子集之间的连接。 我们通过将数据库流量转移到健康区域来缓解这一事件。 我们正在努力使区域数据库更快、更完整地失效,减少超时,使这些网页迅速失效而不是挂起,并增加基于耐久性的警报,以减少我们在今后发现和缓解此类问题的时间。 我们继续与云提供商合作,以了解潜在的网络故障.

自动翻译自官方事件更新。

1. 2026年10月5日 UTC 19:11investigating

   我们正在调查关于行动业绩下降的报告

2. 2026年10月5日 UTC 19:15investigating

   GitHub(GitHub)主持跑道, 一些工作流程可能需要更长的时间才能从跑道配置开始. 我们的团队正在努力缓解这个问题,我们将在了解更多情况时提供最新情况.

3. 2026年10月5日 UTC 19:50investigating

   GitHub 主持选手分配延迟, 我们的团队正在努力减轻影响.

4. 2026年10月5日 UTC 20:39investigating

   GitHub主持跑车任务, 我们的团队正在积极努力减轻影响,并将在我们了解更多情况时提供另一个最新情况.

5. 2026年10月5日 UTC 20:47investigating

   行动在减少。 我们正在继续调查.

6. 2026年10月5日 UTC 21:09investigating

   除了与Actions和Hosted Runners持续出现的问题外,一些客户还无法访问其GitHub账户内的寄存器列表,许可证和账单页. 我们继续进行调查,并正努力减轻影响.

7. 2026年10月5日 UTC 21:22investigating

   页面的性能正在退化。 我们正在继续调查.

8. 2026年10月5日 UTC 21:31investigating

   行动的业绩正在退化。 我们正在继续调查.

9. 2026年10月5日 UTC 21:32investigating

   我们运用了缓解措施来解决 GitHub 动作失败。 排队工作正在清理,新的工作不会被拖延,我们预计很快会完全恢复。 我们继续监测全面恢复情况,并正努力减轻影响其他服务的持续问题,包括查阅储存清单、发放许可证和开具账单等.

10. 2026年10月5日 UTC 21:54investigating

    行动正常.

11. 2026年10月5日 UTC 22:40investigating

    页面正常运行.

12. 2026年10月5日 UTC 22:49resolved

    2026年10月5日,在协调世界时18:48至22:49之间,GitHub Actions和Hosted Runners经历了退化的性能. 整个事件中,14.3%的工作流程使用GitHub托管的跑道运行,26.5%的个人GitHub托管的工作在5分钟内没有开始. 在影响最大的大约90分钟期间,47.0%的工作流程使用GitHub托管的跑道运行失败,71.9%的GitHub托管的工作没有在5分钟内启动,而现有的Pages站点继续正常服务. 部分客户还遇到存储器列表,许可和计费页以及一些副驾驶功能等间歇性错误. 自营跑者没有受到影响。 造成这一事件的原因是部分联网故障,中断了我们一个现场数据中心区域与由云托管的区域数据库和存储服务子集之间的连接。 我们通过将数据库和储存流量转移到健康区域和终点以及提高受影响计算服务的能力来缓解这一事件。 GitHub Actions and Hosted Runners于协调世界时21:54恢复,所有受影响的服务于协调世界时22:49恢复. 我们正在与云提供方合作,以了解网络故障情况并查明如何改进网络-路径复原力、检测和类似事件的恢复.

自动翻译自官方事件更新。

1. 2026年10月1日 UTC 14:47investigating

   我们正在调查关于行动业绩下降的报告

2. 2026年10月1日 UTC 14:54investigating

   我们已查明增加行动的原因,开始拖延Ubuntu跑道的运行,并正在积极部署固定装置。 客户可能会继续经历间歇性延误,而缓解措施则会逐步推出,服务指标会恢复正常.

3. 2026年10月1日 UTC 15:02investigating

   Ubuntu跑道的运行启动延迟问题已经解决。 我们正在调查Windows赛跑者的启动延迟,并将在获得更多信息后分享这些信息.

4. 2026年10月1日 UTC 15:10monitoring

   影响行动的退化已经得到缓解。 我们正在监测以确保稳定.

5. 2026年10月1日 UTC 15:20investigating

   行动的业绩正在退化。 我们正在继续调查.

6. 2026年10月1日 UTC 15:29investigating

   我们看到重新开始拖延的情况再次发生,并正在继续进行调查。 顾客可能会遇到长达10分钟的延误.

7. 2026年10月1日 UTC 16:10investigating

   我们已同我们的上游提供者查明了一个问题,它正在导致429项行动要求,造成拖延。 我们已经升级为拥有的团队,并正在调查如何减轻429起事故.

8. 2026年10月1日 UTC 16:48investigating

   我们目前正在采取缓解措施,预计30分钟内恢复.

9. 2026年10月1日 UTC 17:50investigating

   GitHub Actions公司由于上游Azure属地的挤压,一些主营跑道的性能下降。 服务能力已经恢复,我们正在继续监测,同时与Azure合作处理基本情况.

10. 2026年10月1日 UTC 17:56resolved

    2026年10月1日,GitHub Actions在GitHub托管的跑者上经历了两次延迟和失败的工作开始,从协调世界时约14:15起. 在协调世界时14:15–17:56的事故应对窗口上,大约0.68%的工作流程出现起步延迟,0.196%的工作未能启动。 我国云端提供商的路由变更将API流量集中到一个单一后端,导致利率限制出错增加. 供应商库存服务中不正确的重试行为给受影响的API增加了负载,使费率限制更为复杂. 这扰乱了受影响地区的跑道补给,并削弱了现有能力。 由此导致的未受影响的地区需求的增加暴露了我们工作分配制度的货币限制,即使有跑道者,也拖延了工作。 在答复中,我们增加了工作分配货币,扩大了跑道能力,并与云提供商合作,通过将我们的跑道用户排除在其库存服务之外来减少API负荷。 到协调世界时约16:15时,工作已经开始并按预期执行。 在协调世界时17:56事件得到解决之前,我们继续减缓和监测。 自那以后,我们的云提供方增加了我们工作量的资源管理API费率限制。 为了减少类似事件的可能性和影响,我们还增加了更多的粒状限制费率警报并更新了我们的工作分配系统,以处理较少可用区域增加的需求.

自动翻译自官方事件更新。

1. 2026年10月1日 UTC 13:37investigating

   我们正在调查一些GitHub服务公司受影响业绩的报告.

2. 2026年10月1日 UTC 13:39investigating

   我们正在调查经常发生的影响网络请求的超常时间。 我们将在获得更多信息后分享最新消息.

3. 2026年10月1日 UTC 13:51monitoring

   退化已经得到缓解。 我们正在监测以确保稳定.

4. 2026年10月1日 UTC 13:57resolved

   2026年10月1日,在协调世界时13:04至协调世界时13:34之间,用户在GitHub.com上经历了两段缓慢的页面载荷和间歇性请求失败. 平均误差率为0.52%,最高峰为6.13%. 异常高的流量给我们的交通处理基础设施增加了负荷,在请求到达我们的应用服务器之前就推迟了。 随着交通的平息,性能恢复正常,此后我们采用了额外的交通过滤来防范类似的交通. 我们正在改进对交通处理基础设施延误的警报,并加强我们的自动交通保护,以缩短我们侦测和减缓的时间.

自动翻译自官方事件更新。

1. 2026年10月1日 UTC 11:34resolved

   10月1日 UTC凌晨2点左右,一个孤立的基础设施故障导致GitHub Actions因少数已存在的工作流程运行而失去执行状态. 受影响的运行可能仍然被卡住,部署批准失败,或者在取消时返回错误。 服务连通性已经恢复,但失去的状态无法通过重试批准恢复. 如果你受到影响,你可以触发新的运行,或者联系GitHub Support 与被卡住的运行连接,这样我们就可以解锁它们. 清除后,选择"重新运行所有工作". 这保留了工作流程运行ID,但开始了新的尝试,重建了文物,需要新的部署批准. 在重运行前, 请检查是否已完成任何部署步骤以避免重复更改 .

自动翻译自官方事件更新。