09:58 UTC 那一行我截了图。标题大意是 claude.ai、Claude Code 与 platform.claude.com 出现错误率升高，状态“调查中”，正文一句话，说正在排查影响登录 Claude.ai 和 Claude Code 的问题。受影响服务列了四项：claude.ai、platform.claude.com、Claude Code、Claude Cowork。
11:05，同一个页面，状态换成“监控中”，修复措施已部署，团队在观察恢复。中间 67 分钟。
测试范围先划一下：我不评这次修得快还是慢——那个判断我做不了，理由在下面。我要数的是这份通报里有多少字段是第三方能拿去核查的，以及一条事故从发布到抵达我这台机器，中间隔多久、噪声多大。
结论提前放：两个字段能对得上，其余全是我信它。
67 分钟不是故障时长
这个数最容易被拿去当“故障时长”引用。它不是。起点是“通报已发布”，不是“故障开始”。故障什么时候开始、谁先发现的、从发现到发通报隔了多久——一个都没有。
所以 67 分钟是个下限，而且是截断过一次的下限。真正的 downtime 起点在这份数据里是空的。
我那张表里这一栏从来就没填满过。三十几行记录，来自七八家不同的状态页，“故障开始时间”这一列填上的次数是零。没有一家愿意把“我们发现得晚”写进通报正文。这算不上秘密，就是公开的行业习惯。
逐字段数一遍
两次更新，能被外部核查的信息：
| 字段 | 09:58 | 11:05 | 能否核查 |
|---|---|---|---|
| 受影响服务 | 四项 | 四项 | 能，对得上他们自己的服务清单 |
| 状态词 | 调查中 | 监控中 | 能读，但状态词无定义 |
| 根因 | — | — | 不能 |
| 故障开始时间 | — | — | 不能 |
| 影响用户数 | — | — | 不能 |
| 地域范围 | — | — | 不能 |
| 具体修复动作 | — | “修复措施已部署” | 不能，什么措施 |
“能核查”两栏里，一栏是主语清单，一栏是状态机的当前档位。剩下五行全空。
“监控中”这三个字得单独拎出来说。Statuspage 那套模板里，investigating / identified / monitoring / resolved 是个有序枚举，但它没规定每一档必须写什么。所以“监控中”既可以是“改了配置，看了二十分钟没再报错”，也可以是“整段回滚了，正在等观察窗走完”。字数一样，信息量差一个数量级。我见过最极端的一份通报，从 investigating 一路点到 resolved，三次更新加起来不到四十个词，全程没有一句能复现的描述。
我真正在测的是另一件事
修复时长是他们的 KPI。你多快知道，是你的 KPI。
这两件事在状态页上是同一个页面的两个侧面，但只有一个能被我测。所以我一直在测后面那个：一条事故从发布到抵达我这台机器，中间隔多久，噪声多大。
做法很笨。三条通道同时开：
# 三条探针，各自打 UTC 时间戳，落同一张表
probe_poll = GET https://status.claude.com/api/v2/incidents.json # 每 60s
probe_mail = IMAP 轮询订阅邮箱 # 每 30s
probe_sms = 读手机上收到的短信 # 手动
轮询那条打的是 Statuspage 的公开 incidents 端点，不需要 key，返回结构里每条 incident 带 created_at 和每次 update 的 updated_at，服务端时间戳，精度到秒。这条比我自己在本地打点干净得多。
我一开始是用本地时间打点的。跑了两周发现一个问题：本地时钟漂移。在那台常年不重启的机器上，跟 NTP 的偏差能到几百毫秒量级，秒级比对直接失真。后来 NTP 校时改成 15 分钟一次，这个误差才压下去。
更麻烦的是轮询间隔本身带来的量化误差。60 秒一探，意味着我测出来的“通知延迟”天然带 ±60 秒的量化误差——这个误差比我想测的好几个通道之间的差值还大。说白了，早期那批数字，测的不是通道差，测的是我自己的采样格点。那栏数据我后来标灰了，没删，留着提醒自己。
补救办法是事故 resolved 之后回拉 incidents.json，用服务端的 created_at 反推发布时间，把轮询那条通道的精度从 ±60 秒收敛到几秒。代价是只能事后算，实时告警还是得靠轮询顶着。这个 trade-off 目前没解。
短信那条通道
短信是我表里最难看的一栏。
订阅流程本身就有摩擦：选国家区号，填手机号，收验证码，校验通过才算订上。页面顺带提示可能产生短信与数据费用。
摩擦不是重点。重点是这条链路里有两段完全不透明。一是运营商网关，二是验证码那一关。验证码只在订阅时校验一次，之后是长连接推送，中间掉了你收不到任何提示——你不会知道自己已经脱网了。
我这套东西只挂了一个运营商、一个号。跨运营商的延迟没测到，这是明确的漏控，先记下来，下次补。所以下面这个数是个裸数字，只能当方向看：
过去三十来份同类通报里，短信通道落后页面轮询的时差，中位数落在几分钟这个量级。样本三十几，单运营商，跨地区的没分开算。别拿这个数当准确值，它连置信区间都撑不起来，只能说“短信比页面慢几分钟”这个方向在我这份表里反复出现过。
还有一件没法量化但更烦的事：订阅的是整个页面，不是你的服务。四项服务列在一起，其中三项跟你没关系，每次通报你都得读完才知道和自己有没有关系。久了就静音。静音之后真正相关的那一次，你也不会知道。这一条我在表里只写了一行定性备注，没有数字，就一句话。
缺的那两样，恰好是唯一有用的
根因和影响面，这份通报里一个字没有。这两样也正好是唯一能让你判断“下次会不会再碰上”的信息。
“错误率升高”不是根因，是症状。“四项服务受影响”不是影响面，是主语列表。67 分钟这个间隔，在缺了这两样之后，其实什么都说明不了——修得快可能是因为影响面小，也可能是因为他们直接整段回滚了没细查，外人分不出来。
模板不给字段，也可以在正文里写。这问题出在填不填的选择上，不在工具上。状态页做出来是给用户的，不是给工程的。工程细节要等事后那份东西。
事后那份东西有没有，才是真正的分水岭。一份带根因、带时间线、带“我们哪一步慢了”的复盘，价值比状态页上十条“监控中”加起来都高。而它发不发，跟这次修了 67 分钟还是 6 分钟，没有关系。
置信标签
方向大致对。“这份通报里可核查字段接近零”不是判断，是数出来的——两行能对，五行空着，表在那儿，谁都能自己数一遍。
不确定的部分我也标清楚：那几分钟的通道时差，样本三十几、单运营商、轮询精度被我自己的采样格点污染过一轮，只能当方向参考，别拿去做告警阈值的依据。短信那条通道的跨运营商差异，我根本就没测到。
这套探针脚本我整理一下会放出来，谁想拿自己的订阅链路重测一遍，数字对不上告诉我，尤其是跨运营商那段。