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

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

Git 操作、拉取请求和 Actions 已完全恢复并保持稳定。根本原因已确认，正在采取缓解措施以防止再次发生。

我们观察到所有系统(包括 Git 操作、Pull Requests 和 Actions)已完全恢复。我们将继续调查 UTC 时间 15:06 至 15:16 期间故障的根本原因,并将很快分享进一步更新。

性能下降问题已缓解。我们正在持续监控以确保系统稳定。

性能下降问题已缓解。我们正在持续监控中以确保系统稳定。

影响 Git 操作和 Webhooks 的性能下降问题已得到缓解。我们正在持续监控以确保系统稳定。

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

我们观察到所有系统正在部分恢复。我们将持续监控并调查此次中断的根本原因。

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

Actions 运行正常。

影响拉取请求（Pull Requests）的性能下降问题已得到缓解。我们正在持续监控中，以确保稳定性。

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

Git 操作运行正常。

拉取请求 (Pull Requests) 正遭遇性能下降。我们正在持续调查。

我们观察到在 15:06 UTC 至 15:16 UTC 期间 GitHub 各项服务受到了广泛影响,目前正在调查根本原因。我们看到所有系统正在恢复,稍后将提供进一步更新。

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

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

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

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

2026年10月5日18:48至22:49 UTC期间，GitHub Actions 和托管运行器出现性能下降。在整个事件期间，使用 GitHub 托管运行器的工作流运行中有 14.3% 未在五分钟内启动，单个 GitHub 托管作业中有 26.5% 未在五分钟内启动。


在影响最严重的约90分钟内，使用 GitHub 托管运行器的工作流运行中有 47.0% 失败，GitHub 托管作业中有 71.9% 未在五分钟内启动，而现有的 Pages 网站仍能正常提供服务。部分客户还在仓库列表、许可和账单页面以及部分 Copilot 功能中遇到间歇性错误。自托管运行器不受影响。


此次事件的起因是部分网络故障，该故障中断了我们某个本地数据中心区域与部分云托管区域数据库和存储服务之间的连接。


我们通过将数据库和存储流量转移到正常的区域和端点，并增加受影响计算服务的容量，缓解了此次事件。GitHub Actions 和托管运行器已于21:54 UTC恢复，所有受影响的服务已于22:49 UTC恢复。


我们正在与云服务提供商合作，以了解此次网络故障的原因，并针对类似事件改进网络路径的韧性、检测和恢复能力。

Pages 运行正常。

Actions 运行正常。

我们已采取缓解措施以解决 GitHub Actions 故障。排队的作业正在清空，新作业未出现延迟，我们预计运行器将很快完全恢复。我们将持续监控以确保完全恢复，并正在努力缓解影响其他服务的持续问题，包括访问仓库列表、许可和账单页面。

Actions 遇到性能下降问题。我们将持续调查。

Pages 出现性能下降。我们正在持续调查中。

除了 Actions 和 Hosted Runners 持续存在的问题外,部分客户还无法访问其 GitHub 账户中的仓库列表、许可和账单页面。我们将持续调查并致力于缓解该问题。

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

我们正在继续调查影响 GitHub 托管运行器分配和工作流启动时间的任务失败及延迟问题。我们的团队正在积极采取措施以减轻影响,并将在获得更多信息后提供进一步更新。

我们仍在调查分配 GitHub 托管运行器时出现的延迟问题，该问题影响了多种运行器配置下的工作流启动时间。我们的团队正在努力减轻影响，一旦有更多消息，我们将分享进一步更新。

我们正在调查一个导致为 Actions 作业分配 GitHub 托管运行器时出现延迟的问题。部分工作流在各种运行器配置下可能需要更长时间才能启动。我们的团队正在努力缓解此问题,一旦有更多信息将及时更新。

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

由于上游 Azure 依赖项的限流问题，GitHub Actions 的部分托管运行器出现性能下降。服务容量已恢复，我们将继续监控，同时与 Azure 一起解决根本问题。

我们目前正在应用缓解措施，预计将在三十分钟内恢复。

我们已确认上游服务提供商存在问题，该问题导致 Actions 请求返回 429 错误，从而造成延迟。我们已将此问题上报给负责团队，并正在调查如何缓解 429 错误。

我们再次发现运行启动延迟的问题，并将持续调查此问题。客户可能会遇到最长十分钟的延迟。

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

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

Ubuntu 运行器的运行启动延迟问题已解决。我们正在调查 Windows 运行器的运行启动延迟问题,一旦有更多信息将及时分享。

我们已确认导致 Ubuntu 运行器上 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 作业时出现的故障正在恢复。我们正在持续监控以确认完全恢复。

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