后室中文数据库状态页 - 历史记录

部分 GitHub 项目更新仍有延迟，包括新添加的项目以及对议题和拉取请求的更改。

我们已看到部分恢复迹象，并正在努力增加容量以加快恢复进度。

部分 GitHub Projects 的更新(包括新添加的项目以及对议题和拉取请求的更改)仍然存在延迟。

我们已确认更新处理过程中存在中断,正在评估缓解措施以恢复正常运行。

一些与问题变更和已合并拉取请求相关的 GitHub Projects 更新仍存在延迟。我们正在调查剩余的延迟问题，并努力恢复正常处理。

GitHub Projects 中的部分更新仍存在延迟。我们正在继续进行缓解工作并持续监控中。

其他受影响的服务已恢复。

我们正在继续调查 GitHub Projects，并验证其是否已恢复正常运行。

我们看到受影响的服务正在恢复。GitHub Projects 仍在恢复中，排队的更新正在处理，我们将持续监控以确保稳定性。

在增加容量后，我们看到情况正在恢复，错误正在减少。部分用户在 github.com 上加载 Issues、Pull Requests 和搜索结果时可能仍会遇到错误。

我们将继续努力实现完全恢复，并持续监控稳定性。

部分用户在 github.com 上加载 Issues、Pull Requests、软件包列表和搜索结果时仍然遇到错误。

我们正在采取多项缓解措施，并持续调查中。

API 请求运行正常。

Packages 正在经历性能下降。我们将持续调查。

API 请求正遭遇性能下降。我们将继续调查。

部分用户在 github.com 上加载议题（Issues）、拉取请求（Pull Requests）和搜索结果时仍会间歇性出现错误。

我们正在调查并评估恢复正常服务的应对方案。

部分用户在 github.com 上加载 Issues、Pull Requests 和搜索结果时可能会遇到间歇性错误。

我们正在调查中，并努力恢复正常服务。

此故障已解决。感谢您在我们处理此问题期间的耐心和理解。详细的根本原因分析将在准备就绪后尽快分享。

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

影响 Actions 的性能下降问题已得到缓解。我们将持续监控以确保稳定性。

我们正在观察到恢复情况，代码仓库更新处理已恢复正常。随着我们扩展处理能力，影响 GitHub Actions 工作流和步骤结果的延迟正在持续消退；预计剩余积压还需约 20 分钟才能清空。

仓库更新处理已恢复正常。我们仍在继续处理影响 GitHub Actions 工作流及步骤结果的延迟问题。一旦有进展，我们会再次发布更新。

我们正在调查 GitHub Actions 工作流和步骤结果处理延迟的问题，以及一些仓库更新的问题。

此故障已解决。感谢您在我们处理此问题期间的耐心和理解。详细的根本原因分析将在可用后尽快分享。

拉取请求更新、Actions 和 webhook 投递已恢复正常。审计日志延迟现已低于 40 分钟,处于健康阈值范围内,并随着剩余积压的处理而持续下降。

审计日志事件仍在持续恢复中，目前延迟已降至70分钟以内。我们已采取缓解措施以加快恢复速度，预计审计日志将在约40分钟内完全恢复。拉取请求更新、Actions 和 Webhook 投递仍保持已恢复状态。我们将持续监控进展并分享后续更新。

审计日志事件正在恢复中,随着剩余积压的处理,延迟现已降至90分钟以下。我们已降低了事件流平台的负载,并正在持续监控中恢复情况。后续将有进一步更新。

拉取请求更新、Actions 和 Webhook 投递已恢复。审计日志事件正在恢复，延迟正在减少，但我们预计剩余积压大约需要两到三个小时才能清除。我们正在持续监控中恢复情况，并将分享进一步更新。

操作和 Webhook 投递已恢复。审计日志事件仍延迟约 100 分钟。我们正在处理积压任务,完全恢复还需要一些时间。我们会在恢复过程中分享更多更新。

操作和 Webhooks 运行正常。

审计日志事件仍延迟最多 110 分钟。拉取请求更新已恢复。Actions 正在恢复,用户应该不会再在 Actions 中遇到影响。Webhook 投递在我们处理积压任务的过程中持续恢复。我们正在持续监控恢复情况,并将在了解更多信息后分享进一步更新。

Pull Requests 运行正常。

审计日志事件延迟最长达 100 分钟,Actions 工作流状态更新仍存在较长延迟。随着我们恢复事件处理并清理积压任务,拉取请求更新和 Webhook 投递正在逐步恢复。我们正在持续监控中恢复情况,一旦有进一步消息将及时更新。

审计日志事件和 Actions 工作流状态更新仍存在延迟。随着我们恢复事件处理并清理积压任务,拉取请求更新和 webhook 投递正在恢复中。我们正在持续监控恢复情况,并会在了解更多信息后分享进一步更新。

我们持续观察到拉取请求更新、Webhook 发送以及审计日志事件受到延迟影响。事件流平台已显现恢复迹象,我们将在影响持续期间进行监控。

我们正在调查影响拉取请求更新和 Webhook 投递的延迟问题。事件流处理平台负载增加导致出现热点。我们正在将流量转移出受影响区域并增加处理能力;在这些缓解措施生效期间,影响仍在持续。

Actions 正在经历性能下降。我们正在继续调查。

问题来源是Vercel SSL出错，现已移至Cloudflare。

2026年9月13日,协调世界时(UTC)08:43至10:44期间,GitHub 大约28项服务的可用性下降,受影响服务包括 Issues、Pull Requests、Actions、Codespaces、Pages、Notifications、Code Scanning、Git LFS 以及新账户注册功能。在高峰期,8.8%的 GitHub App 安装访问令牌创建请求失败。Actions 工作流的令牌签发也受到影响,在故障期间大约有4%的工作流受到波及。通过网页界面创建 Issue 的尝试中约有96%失败,注册失败率则超过90%。

故障原因是一个内部数据清理任务,该任务于07:33 UTC开始向一个共享数据库集群写入数据。该集群存储着几乎每个已认证请求都会读取的权限数据。用于控制该后台任务节奏的保护机制只监测了一个健康信号——数据库副本的延迟程度,而该信号在整个过程中一直保持较低水平。它没有考虑到主库本身正在累积的负载,因此该任务持续写入数据,而主库则在悄然逼近其极限。

当主库耗尽可用连接后,需要访问它的请求便无法完成。首先,这些数据库调用没有设置快速超时机制,导致请求处理程序在停滞的数据库上持续等待,而不是快速失败,这使得共享的请求处理能力退化为全站范围的错误。其次,令牌创建过程中的一个重试循环不断重新发送本已失败的写入请求,这使数据库持续处于饱和状态,无法得到恢复。

监控系统于08:50 UTC确认了此次故障,但由于影响范围广泛,加之令牌创建带来的放大效应,定位负载来源花费了一定时间。第一响应人员通过卸载内部负载并暂停该任务进行了缓解,所有服务已于10:44 UTC恢复正常。

为防止此类问题再次发生,我们默认对针对共享的、面向客户的数据库的后台任务进行限流,并新增基于主服务器负载(而不仅仅是复制延迟)的自动暂停和寻呼机制。我们还将在数据库健康信号旁直接展示正在运行的后台任务,以便响应人员无需离开这些仪表盘即可查看并暂停任务;同时对令牌签发路径中的重试次数设置上限,并新增请求级别的超时机制,以防止某一个不健康的数据库耗尽共享网页服务器的处理能力。此外,我们正在拆分这个数据库集群,以消除单点故障。在接下来的两周内,我们将把包括授权数据在内的各项特定服务数据迁出这个共享集群。

拉取请求（Pull Requests）出现性能下降。我们正在继续调查。

我们发现 collab 上的数据库复制延迟增加,导致授权端点的错误率上升,并进一步引发系统整体错误率上升——我们正在调查中

Actions 正在经历性能下降。我们将持续调查此问题。

2026年8月26日21:55 UTC至23:58 UTC期间，2.6%由拉取请求事件触发的工作流运行出现延迟，高峰时期影响一度达到25%。部分用户还遇到了拉取请求合并提交生成、可合并性信息以及合并按钮可用性方面的延迟。Actions 和 Pull Requests 已于23:58 UTC完全恢复；在确认系统恢复正常运行后，事件已于00:26 UTC解决。

处理拉取请求更新和生成合并提交的后台任务受到访问单个 git 数据分区超时问题的影响。这导致拉取请求合并提交处理出现积压，延迟了由拉取请求触发的 GitHub Actions 工作流以及部分可合并性信息。

我们降低了工作负载，将流量从受影响的基础设施上转移，并使受影响的服务组件恢复到健康状态。这些措施共同帮助清理了积压任务，并恢复了正常运行。

我们正在努力改进资源饱和检测能力，并通过隔离影响范围、更好地限制重试次数以及加强背压机制，来消除此类场景下对客户的影响，从而使我们的系统在负载下更具韧性。

影响 Actions 和 Pull Requests 的性能下降问题已得到缓解。我们正在持续监控中，以确保系统稳定。

我们确认服务已于协调世界时（UTC）23:58 开始完全恢复。Actions 工作流运行和拉取请求合并均已恢复正常运行。我们现在将解决此故障，同时将继续监控服务健康状况。

我们已应用缓解措施，并观察到 Actions 工作流运行和被阻塞的拉取请求合并正在恢复。在解决此问题之前，我们将持续监控合并提交创建的稳定运行情况。

我们正在调查影响由拉取请求事件触发的 Actions 工作流运行的延迟和超时增加问题。20% 的 Actions 运行启动延迟超过 5 分钟，最多有 4% 的运行未能触发。我们正在积极处理缓解措施，并将在了解更多信息后提供更新。

2026年8月24日，在UTC时间13:33至14:04期间，3.8%的Actions运行遇到超过5分钟的启动延迟，其中1.25%的Actions运行彻底失败。

此次事故是由于承载多个负责处理运行器分配事件的服务实例之一的节点发生磁盘故障所致。通常情况下，不健康节点上的Pod会被自动移除并替换，不会造成影响。但在此次事件中，尽管该节点严重性能下降、无法执行磁盘操作，它却持续发送健康信号，导致系统无法立即将其工作转移到其他地方。在此期间，分配给受影响组件的事件不断积压，直到UTC时间13:54自动重新平衡将处理转移至健康组件。队列积压于UTC时间14:00清空，处理工作于14:04恢复正常。

为防止此类问题再次发生，我们正在改进对未完全离线的不健康节点的检测与自动修复能力。同时，我们也在加强应用层的韧性，以便能够快速自动移除停滞的消费者，并在无需等待受影响节点恢复的情况下重新分配其工作。

影响 Actions 的性能下降问题已得到缓解。我们正在持续监控以确保稳定性。

部分客户在排队和运行 Actions 作业时出现的故障正在恢复。我们正在持续监控以确认完全恢复。

计划之中的问题，正在迁移主页。