Anthropic的状态页在这个夏天交出了一份看起来相当体面的成绩单：claude.ai 在6月的可用性是99.54%，7月滑到99.01%，8月又回到99.51%。三个数字都站在99%以上，单看这张页面几乎读不出任何异样。但把6月到8月的事故记录一条条摊开会发现，这是一个几乎每周都在出事的夏天，其中一次故障让claude.ai、API、Claude Code和Cowork一起瘫掉。可用性百分比是一种压缩过度的指标，它能把大量短时、局部的故障压成一个不痛不痒的数字，却讲不清故障出在哪一层、伤到了谁、修没修好。
拆开黑箱：一个夏天的十余场故障
6月21日，Downdetector收到超过2000条用户报告，主要症状是"response incomplete"，回复被硬生生掐断。两天后的6月23日，同类故障规模扩大，美国地区的Downdetector报告一度冲到约7119条，是这个夏天用户感知最强烈的一次。第三方网络监控ThousandEyes盯着这次故障看了一个多小时（约14:20到15:20 UTC），发现网络层没有丢包、没有延迟异常——问题出在Anthropic自己的服务端，不是传输路径。
7月17日，claude.ai又遇上一次全球性的"529 Overloaded"过载故障，第三方监控StatusGator记录的影响时长约1小时32分，而且StatusGator比Anthropic官方状态页更早发现了这次异常。8月5日的"多模型性能下降"持续了7小时8分，是三个月里拖得最长的一次广泛性故障。到8月24日，新一起事故从05:06 UTC开始，官方通报只写了"已识别原因"，却没交代具体是什么原因，到06:42 UTC的最新更新时仍未解决。
认证系统崩了，四个入口一起趴下
8月16日的故障最值得记下来。最初表现为身份认证出问题，影响claude.ai、Claude Code、Cowork，随后又扩大到API和Console，前后持续约36分钟（21:58到22:34 UTC）。表面上看，网页、API、Claude Code、Cowork是四个各自独立的产品入口，企业客户如果同时接了网页版和API，通常会觉得自己已经做了一层容灾——一个入口挂了，还能走另一个。8月16日证明这个假设站不住：只要底层的认证或路由系统出问题，四个入口会同时倒下，因为它们共享同一套认证底座。
- 结论.四个产品面共享认证系统，一崩就是全崩，多入口不等于真正的冗余。
可用性百分比说的是结果，不是原因。
官方数字和第三方算的不是一个数
7月的数字最能说明沟通上的落差。官方状态页给出的claude.ai 7月可用性是99.01%，但第三方机构根据事故日志推算出的数字是99.37%，同期claude API的推算可用性则是99.55%——三个数字口径不同，却都指向同一个月份。谁的算法更贴近真实体验，外部很难验证，因为Anthropic几乎从不公开事故根因。状态页上的通报大多停留在"已识别、修复中、已解决"三段式模板，很少往下解释是数据库、路由、容量还是部署环节出的问题。
全行业都在抖，切换竞品不是解药
这个夏天不是Claude一家在出问题。6月10日，Google的Gemini出现涉及错误代码1076和1099的重大故障，同一时间窗口里Claude的Haiku 4.5也出现错误率上升，但没有证据显示两者存在因果关系。7月19日，OpenAI的ChatGPT和Codex在太平洋时间早上7点08分到8点05分之间，因云基础设施维护导致数据库副本不可用而出现容量下降。大模型服务这两年故障率普遍偏高，更像是行业共性，不是某一家的独有毛病。
- 风险.认证层一旦出故障，"多产品面容灾"会同时失效，把生产系统压在单一厂商身上的开发者受影响最直接。
对把生产系统跑在Claude API或Claude Code上的开发者来说，现实的应对不是纠结官方数字准不准，而是假设单一供应商随时可能不可用：请求加上指数退避和幂等处理，长任务留好断点续传，同时用第三方合成监控和官方状态页做交叉验证,而不是只信一个来源。至于把切换ChatGPT或Gemini当作应急预案，同样靠不住——它们自己在同一个夏天也各自宕过。