一个有点刺眼的页面，把 GitHub 过去一年的故障记录画成了红格子。

名字叫 Red Squares。形式很熟：像 GitHub contribution chart。只是原本代表提交和产出的绿色小方块，被换成了代表 incident 的红色热力图。颜色越深，表示当天持续时间越长。

页面给出的数字不轻：过去一年累计约 35.1 天 downtime，170 天至少发生过一次 incident。最严重的一天是 2025 年 11 月 20 日，约 1.1 天。

这里要先压住一个误读。Red Squares 不是 GitHub 官方页面，也不是安全事故或数据泄露通报。incident 也不能直接读成“GitHub 全站瘫痪”。

但它仍然有效。

因为它把一个平时藏在 status page 里的问题，翻译成了开发者每天都看得懂的图：如果代码托管、CI、Issue、Release 都绑在同一个平台上，平台的抖动就不是背景噪音，而是交付风险。

它做了什么：把 status page 变成反向贡献图

Red Squares 的设计很克制。它没有做复杂叙事，只把一年按天切成格子，用红色深浅展示 GitHub incident 的持续时间。

页面文案称它是 “The contribution graph nobody asked for”。讽刺点很直白：GitHub 用绿色方块奖励开发者的连续贡献，Red Squares 用红色方块记录平台出问题的日子。

这招有效，是因为它借用了开发者最熟悉的视觉语法。绿色格子代表“我今天做了什么”，红色格子则变成“平台今天影响了什么”。

几个关键信息需要分开看：

问题Red Squares 的呈现阅读时的限制
数据范围过去一年 GitHub incident 历史不是 GitHub 官方年度稳定性报告
累计时长约 35.1 天 downtime不能等同于全站完全不可用 35 天
发生频率170 天至少一次 incident可能只影响部分服务、区域或功能
最严重单日2025 年 11 月 20 日，约 1.1 天仍需回到具体 incident 看影响面
排除项scheduled maintenance 已排除计划维护不计入故障

数据来自 mrshu/github-statuses 对 githubstatus.com 历史事件的聚合与重建。也就是说，它依赖 GitHub Status 的公开历史信号，但经过第三方项目整理。

所以，这张图不能当官方审计报告看。它更像一张提醒卡：别只看 GitHub 平时像空气一样顺手，也要看它不顺手时会牵动多少流程。

它说明什么：开发基础设施已经成了单点压力源

对普通用户来说，GitHub 出问题可能只是页面慢、仓库打不开。对开发团队来说，影响会具体很多。

PR 可能合不了。Actions 可能排队或失败。Issue 流转会卡住。Release 发不出去。依赖包发布也可能被拖住。

一次 incident 未必让所有团队停工。GitHub 的服务面很宽，Actions、Packages、Codespaces、API、Pages、仓库访问，影响范围可能不同。

真正麻烦的是不确定性。

开发团队最怕的不是“等半小时”。而是发布窗口已经打开，排障群已经拉起，却不知道问题在自己这边，还是平台那边。状态页能给出线索，但很难告诉一个具体团队损失了多少构建时间、多少沟通成本。

这也是 Red Squares 比普通故障列表更扎眼的地方。它没有发明新事实，却把零散事件压成一个年度图形。开发者一眼就能感到：这不是偶发新闻，而是工作流里的长期变量。

横向看，GitLab、Bitbucket、Cloudflare、AWS、Vercel 这类开发与云基础设施服务，也都有 status page。行业现实就是这样：状态页能公开组件级状态和事件时间线，但很少能替每个团队计算真实业务损失。

这不是 GitHub 独有的问题。只是 GitHub 处在太多开发流程的中间，所以红格子更容易刺中人。

真正该做的：少争论红不红，多检查备份链路

Red Squares 最容易引发的争论，是 GitHub 到底“稳不稳”。这个问题可以讨论，但对团队来说不够实用。

更实用的问题是：如果 GitHub 某个核心组件当天不可用，你的交付流程能不能降级？

最相关的两类人，动作不一样。

对象更该检查什么现实动作
依赖 GitHub Actions 的开发团队CI/CD 是否完全绑死在 GitHub保留备用构建路径，关键发布不要只依赖单一队列
有固定发布窗口的技术团队Release、包发布、审批流是否受 GitHub incident 影响给发布预案加一条平台异常分支，必要时延后发布或走降级流程

小团队可以接受偶发等待。成本摆在那里，维护多套链路未必划算。

但对商业团队，尤其是发布节奏稳定、客户承诺明确的团队，情况不同。关键仓库要不要镜像，CI 是否需要备用方案，包发布是否有手动降级流程，都不该只在故障当天临时讨论。

我不太买账的是，把这张图直接拿来证明“GitHub 不可靠”。证据还没到那一步。incident 的范围、持续时间、影响组件，都需要逐条看。

我更在意的是另一件事：GitHub 官方状态页、事后复盘和企业 SLA 信息，能不能给出更清楚的影响边界。

没有边界，开发者只能凭体感判断风险。有边界，团队才知道该不该为镜像、备用 CI、发布降级多付一份成本。

Red Squares 的红格子，最有价值的地方不在红。它提醒的是：当一个工具变成空气，断一下就会让人想起，空气也需要备份。