GitHub Actions 又出问题了。
GitHub 状态页显示，2026 年 5 月 26 日，Actions 与 Pages 出现性能降级。截至材料所示时间，这起事故还没有标记为 resolved，GitHub 也没有公布最终根因。
这件事容易被误读成“GitHub 挂了”。其实不是。代码托管不等于发布流水线，网页能打开也不代表 CI/CD 能跑。
更麻烦的是另一层：很多团队把测试、构建、打包、部署、Pages 发布都接在 Actions 后面。Actions 启不来，或者 action 下载不了，代码还在，交付路径却会变慢。
这次故障卡在 Actions 启动和下载链路
这次事件的已知信息不复杂，但影响点很关键。
GitHub 在 10:57 UTC 开始调查 Actions 和 Pages 的性能下降。11:19，Actions 被标记为可用性降级。11:53，官方更新称正在调查认证问题，问题包括无法启动 Actions runs、无法下载 actions，并称多数 Actions runs 受到影响。
到 12:17，状态仍是 Actions degraded performance，调查继续。
| 时间（UTC） | 官方状态 / 表述 | 对开发流程的影响 |
|---|---|---|
| 10:57 | 开始调查 Actions 与 Pages 性能下降 | 两项服务进入同一 incident |
| 11:19 | Actions 可用性降级 | 工作流启动不稳定 |
| 11:53 | 认证问题影响启动 runs 和下载 actions | 官方称多数 Actions runs 受影响 |
| 12:17 | Actions 性能降级，仍在调查 | 未显示恢复，根因未公布 |
状态页同时显示，Actions 为 Degraded Performance，Pages 也为 Degraded Performance。
这里要分清边界。材料不能支持“Pages 独立故障”这个说法。更稳妥的判断是：Pages 与 Actions 出现在同一 incident 下，而不少 Pages 构建和发布本来就依赖 Actions。
所以，影响不是“所有 GitHub 页面都不能访问”。影响更像是：自动化链路的前段开始抖。run 启动不了，action 拉不下来，后面的测试、构建、发布自然排队或失败。
最受影响的是把发布押在 Actions 上的团队
对依赖 GitHub Actions 的团队，这不是一个单纯的开发体验问题。
很多仓库把 Actions 用在 pull request 检查、Docker 镜像构建、npm 或 PyPI 发布、Terraform 部署、GitHub Pages 自动上线。认证链路出问题时，流水线可能连第一步都走不稳。
最相关的两类人会立刻受影响。
一类是负责生产发布的工程团队。比较现实的动作是延后发版窗口，暂停依赖自动部署的合并，或者临时切到手动发布、备用 runner、备用 CI。不能只看“代码是否已经合入”，还要看“合入后能不能可靠交付”。
另一类是维护开源项目和文档站的人。release 可能卡住，PR 检查可能挂起，Pages 文档站更新可能延迟。对外看只是一个绿色勾没出来，对维护者来说，后续沟通、合并节奏和版本发布都要跟着改。
这次事故还有一个现实限制：状态页不会告诉每个仓库的失败概率，也不会替团队判断要不要取消发布。
官方说“多数 Actions runs 受影响”，这个表述已经足够重。但它仍不能推出本次故障的具体百分比、持续时长或根因。现在能确认的是影响面，不是完整病因。
两周内三次相关事故，不能只当偶发噪声
5 月 26 日这次事故之前，Actions 在 5 月已经有两次值得放在一起看的记录。
5 月 20 日，Actions 出现 run start delays。官方事后称，16:00 至 17:45 UTC 期间约 4.5% runs 延迟，scale set jobs 受影响更重，根因为内部服务健康检查配置问题。
5 月 15 日，Actions 降级在峰值导致 42% runs 失败，并影响包括 Pages 在内的下游服务。官方给出的原因，与一次支撑基础设施的计划故障转移及服务发现更新异常有关。
| 日期 | 公开影响 | 已知根因 | 和本次的关系 |
|---|---|---|---|
| 5 月 15 日 | 峰值 42% Actions runs 失败，Pages 等下游受影响 | 故障转移与服务发现异常 | 说明 Actions 故障会牵动下游链路 |
| 5 月 20 日 | run start delays，约 4.5% runs 延迟 | 内部健康检查配置问题 | 同样集中在 run 启动体验 |
| 5 月 26 日 | 多数 Actions runs 受影响 | 尚未公布 | 只能观察模式，不能套用历史根因 |
这三次不能简单合并成同一个原因。5 月 26 日的根因还没公布，把前两次原因直接套上去，是不严谨的。
但它们至少说明一件事：Actions 的稳定性已经不是边角变量。它处在很多团队交付链路的中间位置。它一抖，影响会从 CI 扩散到发布、文档、包分发和基础设施变更。
GitHub Actions 的优势，正是这种深度集成。代码、权限、Secrets、runner、Marketplace actions 都在同一个平台里流转。平时省事，故障时也更难绕开。
接下来最该看三个问题。
- GitHub 是否公布 5 月 26 日事故根因，尤其是认证问题具体落在哪一层。
- 认证问题是否只影响 Actions，还是触及更广的 token、权限或下载链路。
- GitHub 是否会针对 5 月连续事故给出工程修复，而不只是把状态页改回绿色。
对工程负责人，判断可以更直接一点：关键发布不要只准备一条流水线。
最低限度，也该有手动部署文档、临时冻结策略、备用 runner 或备用 CI 的预案。小团队未必需要马上迁移平台，但至少要知道：当 Actions 不可用时，谁有权限发版，怎么发，哪些发布必须暂停。
这才是本次故障给人的提醒。不是 GitHub 不能用，而是 CI/CD 依赖越深，故障成本越容易藏在日常效率后面。