GitHub 这次不是一个按钮坏了。
根据 GitHub Status 官方状态页，2026 年 5 月 4 日 15:45 UTC，Issues 和 Webhooks 率先被标记为 degraded performance。几分钟后，Git Operations、Pull Requests、Actions、Packages 也陆续出现 degraded performance、degraded availability，以及 increased latency and timeouts。
这件事需要先压住一个说法：目前不能写成 GitHub 全站彻底宕机。官方确认的是多项服务降级，且仍在调查。
但它也不是小问题。因为被影响的服务，刚好串起了很多团队每天最核心的研发协作链路：写 issue、提代码、开 PR、跑 CI、发包、触发外部系统。
时间线：从 Issues 和 Webhooks 扩到多项服务
官方最早提到的是 Issues 和 Webhooks。这个起点很关键。
Issues 影响协作入口。Webhooks 影响外部系统触发，比如部署、通知、工单同步。随后 Git Operations、Actions、Pull Requests、Packages 加入，事件性质就变了。
它更像一次链路型降级，而不是单点页面异常。
| 时间（UTC） | 受影响服务 | 官方表述 | 可能影响的开发动作 |
|---|---|---|---|
| 15:45 | Issues、Webhooks | degraded performance | issue 操作变慢，外部回调延迟或超时 |
| 15:48 | 多项 GitHub 服务、Git Operations | increased latency and timeouts、degraded performance | push、pull、clone 等 Git 操作延迟或失败 |
| 15:50 | Packages | degraded performance | 包下载、发布、依赖获取受阻 |
| 15:51 | Actions、Pull Requests | degraded performance / degraded availability | CI 任务、PR 审查和合并节奏受影响 |
| 15:56 | Pull Requests | degraded performance | PR 页面或相关操作仍不稳定 |
这张表里最值得看的是服务之间的关系。
Git Operations 是代码流转的底座。Pull Requests 是审查和合并入口。Actions 接着测试、构建和发布。Packages 负责依赖和制品分发。Webhooks 又把 GitHub 的状态传到外部系统。
单个环节慢，团队还能绕一下。几个环节一起慢，流水线就会开始抖。
影响最大的，是依赖 CI/CD 的研发团队
对普通访问者来说，GitHub 页面慢一点，可能只是体验差。
对企业研发和 DevOps 团队来说，问题更具体：PR 合并可能卡住，Actions 任务可能排队或超时，依赖包拉取失败会让构建中断，Webhook 超时还可能让外部系统拿不到最新状态。
这就是开发基础设施和内容网站的差别。
内容网站慢，用户多半刷新。研发平台慢，团队会开始判断：这次发布还推不推？构建失败算代码问题，还是平台问题？同一个包要不要重新发布？Webhook 没触发，要不要手动补一次？
最相关的两类人，动作会不一样。
| 对象 | 眼前最该做的事 | 不建议做的事 |
|---|---|---|
| 依赖 GitHub Actions 的研发团队 | 暂停非紧急发布，保留构建日志，记录失败时间点 | 在平台不稳定时反复重跑任务，把队列和判断都打乱 |
| 负责发布和 DevOps 的团队 | 检查包缓存、部署触发、Webhook 到达情况，必要时切到人工确认 | 把所有失败都归因于代码变更，急着回滚或重复发包 |
这里也要给一个限制。
GitHub 目前没有披露受影响用户规模、地区范围、错误率，也没有给出根因。它可能影响到一部分团队，也可能在不同地区、不同仓库、不同服务上表现不同。
所以现在最稳妥的写法是：多服务降级，影响研发协作链路；不是全站宕机，也不能推断为攻击事件或大规模业务损失。
还没到复盘阶段，先盯三个确认点
截至材料时间，GitHub 的表述仍是正在调查。官方没有给出根因，也没有给出恢复时间。
这意味着，现在猜数据库、网络、队列、内部组件都没有意义。没有证据，就不要把推测写成结论。
接下来更该盯三件事。
| 观察点 | 为什么重要 | 怎么判断 |
|---|---|---|
| 组件状态是否恢复 | 只恢复 Issues 不够，Git Operations 和 Actions 仍可能阻塞研发 | 看 GitHub Status 中相关组件是否从 degraded 调回正常 |
| 关键链路是否同步恢复 | PR、CI、包分发任何一环不稳，发布仍会受影响 | 看 Pull Requests、Actions、Packages 是否一起稳定 |
| 是否发布根因说明 | 没有 root cause，就很难判断复发风险和应急策略 | 看是否有 incident update 或 post-incident review |
这类事件还有一个现实对照。
团队把代码托管、评审、CI、包管理集中在一个平台上，平时效率很高。权限、审查、自动化和发布都能连起来。但一旦平台多服务降级，风险也会顺着同一条链路传下去。
这不是说企业应该立刻迁移。迁移本身成本很高，工具链、权限、历史记录、自动化脚本都要改。
更现实的做法，是给关键发布留缓冲：重要依赖做缓存，发布窗口避开高风险时段，CI 失败保留证据，Webhook 触发结果要能人工核对。
状态页只能告诉你平台怎么了。它不会替团队判断哪次构建该重跑，哪个包该重发，哪个发布该暂停。
回到这次 GitHub 事件，关键不在“是不是全站挂了”这个标签。关键在于，多个看似独立的服务一起降级后，开发协作会从顺滑变成不确定。