GitHub Actions 遭遇故障，工作流启动失败
GitHub Actions and Pages are experiencing degraded availability
GitHub Actions 近期出现服务异常，导致部分工作流无法启动或在运行中途失败，同时 Actions REST API 请求也频繁报错。部分用户还遭遇了意外的速率限制。GitHub 工程师已定位问题源头并正在积极修复。此次事件同时影响了 Pages 服务的性能。对于依赖自动化流程的开发者而言，这次中断无疑是一次严峻的考验，也提醒我们云端基础设施的脆弱性。
工程师已定位到干扰源，并正在积极实施缓解措施。
HN 评论区
404- zehaeva
所有的故障在我看来都是扩展性问题。每个月，GitHub 收到的提交量都相当于往年一整年的量，而且还在持续增长。
> 没错，平台活跃度正在激增。2025 年共有 10 亿次提交。现在每周有 2.75 亿次，如果保持线性增长，今年将达到 140 亿次（剧透：不会的。）
GitHub Actions 的用量从 2023 年的每周 5 亿分钟，增长到 2025 年的每周 10 亿分钟，而本周截至目前已达 21 亿分钟。
因此，我们正在全力增加 CPU 资源、扩展服务规模，并强化 GitHub 的核心功能。
作为一个多年来精心打造“垃圾代码”的行家，我就不对此发表意见了。
x.com/kdaigle/status/2040164759836778878
- __initbrian__
我觉得这对整个软件行业来说不是什么好兆头。
我们使用 LLM 来处理所有主要软件组件已经一年多了，而这些软件是我们赖以生存的，可 GitHub 现在的可用性却只剩下了一个 9（90%）。我用 GitHub 已经很长时间了，我第一次提交可以追溯到 2009 年 8 月！说实话，我不记得 GitHub 在过去的一年里宕机这么频繁。
我确信后台还有其他事情在发生，但我忍不住认为这与 LLM 使用量的增加直接相关。
不过，我很想听听其他人的理论，解释一下这个互联网基石是如何从四个 9（99.99%）的可用性跌落到可能只有一个 9 的。
- molsson
已经宕机 5 个小时了，整个服务依然完全不可用。这种无能程度以及他们对客户彻底的漠视简直令人难以置信。
- m132
到了这个地步，他们是不是该考虑只在服务恢复正常时才发布公告？
- arandomhuman
已经好几个小时了 :(
我对正在努力解决问题的值班团队表示同情，我们大多数人都经历过这种情况。
但看起来 GitHub 内部似乎存在系统性的问题。
- alamsterdam
我特别喜欢的一点是，即使是自托管的 worker 在这些故障期间也无法工作——在他们的基础设施上运行任务偶尔不稳定勉强还能接受，但仅仅是用来调度工作流的 API 可用性都这么差，这简直让人匪夷所思。GitHub 看起来已经不再像一家严肃的公司了。
- peterldowns
从 GitHub Actions 切换到其他 runner 并不难。例如，我整理了使用 Hugging Face Jobs 所需的步骤，它还支持 GPU runner 和其他类型。我在管理的几个仓库（例如 Trackio）中都在使用：
- opiniateddev
鉴于最近频繁发生的故障，我想知道有多少人正在认真考虑除了代码托管之外，将其他业务（比如 Actions/工作流）迁移出 GitHub。