Hacker News 中文摘要

RSS订阅

Incident with Actions, Pull Requests and Issues

原文链接 | HN讨论 | 2026-10-13 02:19:57

网页与邮件通知（web and email notifications）仍在处理积压通知（notifications）而持续延迟，这条更新发布于2026年10月12日 17:34 UTC。15:50 UTC的更新称通知（notifications）已经恢复，但因处理积压仍会延迟；15:19 UTC时团队已成功应用通知缓解措施，通知恢复后依然因积压而延迟。14:37 UTC时，操作（Actions）、议题（Issues）和项目（projects）的问题已缓解，同时正在实施缓解措施以应对通知延迟。

正文

更新

我们正在清理通知积压，网页和邮件通知仍持续延迟。

发布于 2026 年 10 月 12 日 17:34 UTC

更新

通知已恢复，但在清理积压期间仍会持续延迟。

发布于 2026 年 10 月 12 日 15:50 UTC

更新

我们已成功对通知问题实施缓解措施，通知已恢复，但在清理积压期间仍会继续延迟。

发布于 2026 年 10 月 12 日 15:19 UTC

更新

我们已缓解 Actions、Issues 和 Projects 的问题，并正在实施缓解措施以解决通知延迟。

发布于 2026 年 10 月 12 日 14:37 UTC

更新

影响 Actions 的性能下降已缓解。我们正在监控以确保稳定。

发布于 2026 年 10 月 12 日 14:36 UTC

更新

影响 Issues 的性能下降已缓解。我们正在监控以确保稳定。

发布于 2026 年 10 月 12 日 14:35 UTC

更新

我们最初的缓解措施并未完全成功，用户在 Actions、Issues 和 Projects 上仍可能遇到延迟和错误，通知也出现延迟。我们正在继续调查根本原因并研究更多缓解措施。

发布于 2026 年 10 月 12 日 13:38 UTC

更新

Pull Requests 目前运行正常。

发布于 2026 年 10 月 12 日 13:02 UTC

更新

缓解措施正在进行中，我们正监控恢复情况。在缓解期间，用户也可能遇到网页通知延迟。

发布于 2026 年 10 月 12 日 12:57 UTC

更新

用户在加载 Actions 标签页界面、与 Checks API 交互、排队新的 Actions 运行、创建和更新 Issues，以及请求 PR 评审时可能会遇到问题，包括通过 REST 和 GraphQL API。

发布于 2026 年 10 月 12 日 12:33 UTC

调查中

我们正在调查关于 Actions、Issues 和 Pull Requests 性能下降的报告。

发布于 2026 年 10 月 12 日 12:21 UTC

本次事件影响：Issues、Pull Requests 和 Actions。

评论

社区气氛以疲惫的吐槽和讽刺为主，主线分歧在于 GitHub Actions 是否还值得继续使用。多数人质疑其可靠性与免费模式，主张少依赖、自建、手动触发、收费限流或换用竞品；少数人则把问题归因于极端规模增长、Git 自身的扩展难度或微软收购后的反垄断失灵，认为团队已在尽力。

认为 GitHub CI/CD 已不可靠，应改用自建、手动触发或竞品

  • 许多评论表示不再把 GitHub Actions 当作关键依赖：自建运行器、家庭服务器、通用 Docker、Forgejo，或直接回流 Azure DevOps 都更可控；也有人关掉推送即触发、只在发版时手动跑 CI，甚至建议把 Actions 改成必须自托管并给 GitHub Desktop 配 Actions 插件，AI 进一步降低了自建门槛。（认可度：高赞）
  • > 我不明白为什么大家都把自己锁进 GitHub 的 CI/CD，自己控制的机器跑构建其实更快也更可靠（@zanderwohl）

认为 GitHub 故障已常态化，社区只能靠讽刺消化

  • 频繁事故让不少人默认它随时会坏，甚至建议反过来只在服务正常时发状态提醒，或等哪天没故障再上 Hacker News；这类讽刺本身成了社区情绪的出口。（认可度：较多人）
  • > 与其每次坏了都发帖，不如改成哪天没故障再上 Hacker News（@loveparade）

认为免费额度和滥用正在拖垮服务，应当收费或分层限流

  • 不少人把问题指向少数重度用户和免费仓库：前 0.05% 的用户制造了大部分乱象，GitHub 应该向他们收费、砍掉免费仓库，或用 Actions Free/Plus 分层、把更新推到用户自己的智能体基础设施来分流，哪怕免费分钟变少也要换回可靠。（认可度：较多人）
  • > 造成这些破事的其实是前 0.05% 的用户，GitHub 应该向他们收费，先服务好大多数人（@sergiotapia）

认为 AI 自动生成的项目和智能体工作流正在制造前所未有的负载

  • 有评论指出，大语言模型能在几分钟内做出可运行的端到端集成，人人都能批量生产上百个项目或自动化，GitHub 的架构和经济模型并不是为这种智能体洪流设计的；这也和“谁的智能体这次跑出来了”的调侃相呼应。（认可度：较多人）
  • > Claude 几分钟就做好了监听提交并控制灯泡的完整项目，GitHub 本来就不是为这种规模化自动化场景设计的（@orsenthil）

认为问题主要是极端规模增长，不是 GitHub 无能

  • 少数人为 GitHub 团队辩护：任何系统从每天 5000 万量级涨到 20 亿量级都会连环崩溃，补丁打完下一块骨牌又会倒，这更像是成长中的机会而非单纯无能。（认可度：少数人）
  • > 从每天 5000 万涨到 20 亿，几乎任何人建的系统都会崩，修完一个下一个又倒（@bearjaws）

认为根源可能在 Git 本身的扩展性，而不是 GitHub 运维差

  • 有评论提出二选一：要么 GitHub 运维大不如其他大厂，要么 Git 本身带来独特扩展挑战；作者更倾向后者，甚至质疑是否应另起炉灶做更易扩展的版本控制系统，再由 GitHub 用成本或可靠性推动迁移。（认可度：少数人）
  • > 要么 GitHub 运维不如其他大厂，要么 Git 本身带来独特的扩展难题，我更倾向后者（@kqgnkqgn）

认为微软不该被允许收购 GitHub，问题根源在反垄断失灵

  • 少数人把可靠性问题上升到市场结构：微软收购 GitHub 后缺乏竞争约束，导致整个生态为可靠性买单，反垄断缺失才是更深层病因。（认可度：少数人）

有价值的补充

  • bob1029 的绕开 Actions 方案：远端只保留环境对应的常驻分支，目标机轮询该分支最新提交，检测到变更就在本地重建；只要 Git 核心操作还在就能持续运行，也方便换供应商。
  • mmnfrdmcx 用小团队 Forgejo 加自托管持续集成，装在 Framework 台式机上，通过 Tailscale 连接，实测很稳，换来自主感。
  • colek42 指出把 CI 当提交门禁不可扩展，更好是把测试推到本地，用 pushgate.dev 之类的服务验证智能体是否真跑过测试并生成来源证明。
  • fschuett 直接关掉 CI，改用专门的“ci run”评论手动启动，只需要生产发布前是绿的，不必每个提交都跑 CI，从使用习惯上减少无效负载。