Anthropic 于 8 月 16 日记录了一次服务中断，最初表现为登录失败，随后扩散为五款产品的性能下降。状态页将事件开始时间标为 UTC 21:58，结束时间标为 UTC 22:34：共计 36 分钟。
按官方发布的时间线
共有四次更新，均以 UTC 标注。21:58："We are investigating an issue with users authenticating to claude.ai, Claude Code, and Claude Cowork." 22:02，影响范围扩大为 "degraded performance affecting claude.ai, platform.claude.com, the Claude API, Claude Code, and Claude Cowork"。22:22，已部署修复并进行监测。22:34，事件被标记为已解决。
常见说法错在何处
目前流传的有两个数字和一个影响范围说法均不准确。如今在汇总信息中反复出现的持续时间是 42 分钟。这一数字来自一篇于 UTC 22:40 发布的报道——当时事件尚未结束——并将该记者观察到情况恢复的时刻当作恢复时间。Anthropic 自己的页面则将其结束时间记为 22:34。应采用第一手时间戳。
早期报道还称 Claude API 和 Console 未受影响。最终的修复说明将 platform.claude.com 和 Claude API 列为受影响组件之一。API 受到性能下降影响，而不是与问题无关。
此外，"outage" 夸大了第一阶段的严重程度。前四分钟，故障被明确描述为 authentication——用户无法登录，而不是服务完全停止响应。这个区别很重要，因为两种故障模式的影响范围不同：已登录的长连接会话可能继续运行，而新的登录会失败。
尚未公布的内容
目前尚未公布根本原因。 没有事后复盘，没有促成因素说明，也没有说明认证失败是否导致了更广泛的性能下降，还是后者的首个症状。任何声称已知原因的说法都只是推测。
为什么 36 分钟并不算短
关键在于受影响名单。Claude Code 和 Claude Cowork 属于付费工程工作流，而不是聊天窗口。认证层故障在这里不会平稳降级——它会让客户现场、客户截止期限上的工作直接停摆，且没有本地替代方案。这样的 36 分钟，与一个消费级助手变慢的 36 分钟完全不同；也正因如此，未公布原因才是更值得关注的长期新闻。