一个叫isgithubcooked.com的非官方网站最近火了。它把GitHub Status十年来的公开事故记录做成了可视化面板，结论听起来挺吓人：GitHub自2016年3月以来共发生1125次事故，月均24次，2026年2月是史上最差月份，单月37次。Copilot可用性只有97.93%，Actions是98.21%，是所有服务里垫底的两项。
这些数字确实抓眼球，但把它们直接等同于"GitHub越来越不稳定"，是个陷阱。同一个2月，GitHub官方发布的月度可用性报告只认定了6次"导致服务下降的事件"。第三方口径和官方口径，相差六倍还多。
50条记录之外，历史是怎么"拼"出来的
GitHub Status背后跑的是Atlassian的Statuspage系统，官方事件API只返回最近50条记录，没有直接的十年历史接口。像isgithubcooked.com和另一个同类站点githubdownfall.com这样的第三方工具，必须靠抓取历史页面或feed去重建全部数据，具体怎么去重、怎么合并、时间戳怎么取，两家都没公开说明。
这不是指责它们造假——githubdownfall.com独立统计出的2026年2月37次事故，和isgithubcooked.com的数字完全吻合，说明抓取本身是可信的。但"抓到了多少条状态页记录"和"用户实际感受到多少次真实故障"，从一开始就是两件事。isgithubcooked.com此前的一次快照显示总事故数是1118，本文引用的数字已经涨到1125——这套统计还在实时滚动变化，本身就说明它更像一个动态计数器，而非盖棺定论的历史评价。
同一个2月，官方为什么只认6次
关键的反转在这里：GitHub官方2026年2月的可用性报告把状态页上多条记录按根因合并统计，认定当月只有6次真正导致服务下降的事件。第三方统计的37次，很大程度上是把同一根因触发的多个组件状态变化，各算了一遍。
- 结论.状态页的"事件数"统计的是记录条数，不是故障次数；一次根因引发8个组件掉线，会被记成8条。
Minor级别事故在总数里占了81%（911/1125），很多是短暂降级甚至维护通知，跟Critical级别的真正宕机权重完全不同，混在一起报总数会人为放大"要崩了"的观感。
2月9日到底发生了什么
官方6次事件里最典型的一次，链条能完整还原。GitHub在推出新模型前，把用户设置缓存的刷新TTL从12小时调到了2小时——本意可能是让配置更新更快生效。结果两款主流客户端同期发布新版本，读取这份设置的流量暴增10倍以上，直接压垮了负责认证和用户管理的核心数据库集群。
数据库一倒，GitHub.com、API、Git操作、Actions、Copilot、Issues、Pull Requests、Webhooks连环掉线，这就是官方6次事件里权重最大的一次，也是很多开发者当天真实感受到"GitHub崩了"的时刻。同月2日的另一次大故障，起因是云厂商调整了存储策略，导致托管Runner的虚拟机元数据访问被封锁，Actions没法创建、删除或重新镜像Runner，连带Codespaces、Copilot Coding Agent、CodeQL、Dependabot、Pages一起趴窝——好在自托管Runner没受影响，这也是很多重CI团队后来把关键流水线迁到自托管的直接动因。
该看的不是总数，是哪几项、多久
对依赖Actions、Codespaces、Copilot做CI/CD和辅助编码的团队来说，"官方6次"和"第三方37次"哪个更贴近真实体验，答案其实是"都不完全对"。真正该盯的是具体哪个组件出问题、级别是Major还是Critical、恢复用了多久——这些原文面板里其实都有，只是被总数的耸动感盖住了。
GitHub官方也承认2月的系统性问题有四个结构性根子：负载增长太快、核心服务之间架构耦合太紧、缺乏有效的负载削减机制、监控和故障隔离存在盲区。这四条如果后续几个月能看到改善，比任何一个滚动百分比都更能说明问题是否真被解决。GitHub在2月13日上线了90天滚动可用性展示，这意味着原文里97.93%这类数字是滚动窗口快照，不是严格的自然月统计，下次再看到类似面板，先确认清楚它算的是哪段时间。
数字越吓人，越该先问一句：谁在数、怎么数的。
对企业客户和SRE团队来说，与其纠结总事故数，不如把Actions和Copilot这类新产品线的自托管备份方案提前备好——2月2日那次故障已经证明，自托管Runner是这类云厂商侧故障里少有的安全区。