怎么看 OpenAI 状态页和 Claude 状态页：事件等级、组件与真实影响
OpenAI 状态页和 Claude 状态页回答的是“厂商确认了什么”，不是“你此刻能不能用”。读的时候先看页面总体等级（indicator），再看你用到的那个组件，最后看事件处在哪个阶段，三者对上了，才能判断这次故障和你有没有关系。状态页上的事件需要人工确认后才发布，往往晚于故障实际开始的时间，所以排查时还要拿独立的 API 探测和用户报告来对照。文末有一份可以直接照做的排查清单。
页面顶部的绿、黄、橙、红横幅分别是什么意思？
很多 AI 厂商的状态页托管在 Atlassian Statuspage 上，或者沿用类似的数据结构。以 Statuspage 为例，页面顶部那一行“All Systems Operational”或者彩色横幅，对应接口里的 status.indicator 字段，常见取值有五个（颜色是默认主题，厂商可以自定义）：
| indicator | 页面上通常显示 | 含义 | 对开发者的提示 |
|---|---|---|---|
none | 绿色，全部正常 | 没有进行中的事件 | 只代表厂商没有登记事件，不代表你的请求一定成功 |
minor | 黄色 | 有轻微影响的事件，常见于部分功能变慢或少量报错 | 先查是不是你用的组件 |
major | 橙色 | 有较大影响的事件，部分组件明显不可用 | 生产流量考虑降级或切换备用方案 |
critical | 红色 | 有严重事件，核心服务大面积不可用 | 停掉密集重试，等恢复 |
maintenance | 蓝色 | 正在进行计划维护 | 看维护窗口和受影响组件 |
有两处容易读错。
第一，顶部等级反映的是当前最严重的那个问题。页面上同时挂着一个 minor 和一个 major 事件时，顶部显示 major。如果这个 major 事件只影响图像生成，而你只调用文本接口，你可能完全不受影响。
第二，等级由厂商自己定，不同厂商之间不可比。同样是“部分用户报错”，有的团队标 minor，有的标 major。后文的数据里可以看到，各家的等级分布差别很大。
我该看哪个组件？
状态页的第二层是组件（components）。AI 厂商常把服务拆成网页端、API、具体产品线、控制台、登录、计费等多个组件，每个组件有独立状态：
| 组件状态 | 含义 |
|---|---|
operational | 正常 |
degraded_performance | 性能下降：能用，但变慢或偶发失败 |
partial_outage | 部分中断：一部分请求或一部分用户失败 |
major_outage | 严重中断：大部分请求失败 |
under_maintenance | 维护中 |
开发者最常遇到的错位是聊天网页出了问题而 API 正常，或者反过来。所以先弄清自己的调用链依赖哪几个组件，例如：
- 用官方 SDK 调 API：看 API 组件，以及你用的那类能力（文本、图像、语音、文件等）对应的组件。
- 用命令行编程工具：除了 API，还要看该工具本身和登录、鉴权相关的组件。
- 只在网页端聊天：看网页端和登录组件。
组件状态和事件等级是两套字段。一个事件可以关联多个组件，事件的 impact 取 none、minor、major、critical 之一，组件状态则是上表五种之一。判断影响面时，组件状态比事件标题具体。
事件从 investigating 到 resolved，每个阶段该怎么应对？
Statuspage 上事件的标准阶段如下：
| 阶段 | 字段值 | 实际意味着什么 |
|---|---|---|
| 调查中 | investigating | 厂商已注意到异常，原因未明，影响范围可能还会扩大 |
| 已定位 | identified | 找到原因，正在修复 |
| 观察中 | monitoring | 修复已上线，正在确认是否恢复，请求可能仍有零星失败 |
| 已解决 | resolved | 厂商认为已恢复 |
| 复盘 | postmortem | 发布了事后分析，不是每个事件都有 |
计划维护另有一套阶段：scheduled（已排期）、in_progress（进行中）、verifying（验证中）、completed（完成）。
处在 monitoring 阶段时，不要一次性恢复全部流量，先放一小部分进来看错误率。resolved 之后你这边仍然报错，先查客户端缓存、连接池和自己的网络链路。
各家状态页的事件等级能直接比较吗？
不能。cdnping 每 15 分钟同步 OpenAI、Anthropic、Moonshot、Groq、Cloudflare、GitHub、Cursor 的官方状态页。下表是从这些状态页同步到的事件，窗口为 2026-09-17 至 2026-10-17，按事件 impact 计数（来源：各官方状态页，经 cdnping 汇总）。cdnping 从 2026-10-17 才开始采集，这里的一个月数据来自状态页自身保留的历史记录，不是 cdnping 的长期观测。
| 状态页 | critical | major | minor | none | 合计 |
|---|---|---|---|---|---|
| OpenAI | 0 | 4 | 19 | 2 | 25 |
| Claude（Anthropic） | 0 | 6 | 1 | 1 | 8 |
| Moonshot | 8 | 0 | 0 | 0 | 8 |
| Groq | 0 | 1 | 2 | 0 | 3 |
| Cloudflare | 0 | 3 | 19 | 3 | 25 |
| Cursor | 0 | 5 | 20 | 0 | 25 |
| GitHub | 5 | 1 | 10 | 0 | 16 |
从表里能看出几点：
- 事件多不等于更不稳定。OpenAI 的 25 个事件里有 19 个是
minor，可能说明它习惯把局部问题也登记出来；Claude 状态页事件总数少，但 8 个里有 6 个标为major。这些数字更多反映登记习惯，不能当可用率直接比。 - 同一个等级在不同厂商那里分量不同。Moonshot 窗口内的 8 个事件全部标为
critical，没有更低等级的记录。所以不要把“critical 次数”当作稳定性排名。 - 事件时间不一定准。cdnping 同步到的最近 40 条事件里，有 7 条按“解决时间减创建时间”算出的时长是负数；GitHub 还有标题带“[Retroactive]”的事件，也就是事后补录的。状态页上的起止时间适合粗略定位，不适合精确计算停机时长。
再看一个状态页显示正常、探测却有失败的例子。cdnping 在 2026-10-17 UTC 08:40 至 10:05 的边缘探测快照（Cloudflare 丹佛节点，共 242 次探测，覆盖 15 个 API 入口）中，Moonshot API 入口的成功率为 94.4%，同一时刻它的官方状态页 indicator 是 none。窗口只有一个多小时，不能据此说这个服务不稳定，但它说明了一个常见情况：少量失败往往达不到厂商登记事件的门槛。
状态页显示正常，为什么我还是连不上？
状态页有几处固有的盲区：
- 滞后。事件要人工确认后才发布，故障开始到出现
investigating之间通常有一段空档。 - 门槛。只影响少数用户、少数地区或某类账号的问题，可能不会被登记。
- 视角单一。状态页反映的是厂商内部监控，看不到你的网络到 API 入口之间的链路。从中国大陆访问海外 API 时，不少“连不上”就发生在这一段，厂商状态页不会显示。
- 粒度粗。组件划分由厂商决定，不一定细到你用的那项能力。
- 体验类问题不在上面。“回答质量变差”“额度突然被重置”“被登出”这类问题，一般不会出现在状态页上。
怎样用 API 探测和用户报告交叉验证？
三类信号各自回答不同的问题：
| 信号 | 回答的问题 | cdnping 对应页面 |
|---|---|---|
| 官方状态页 | 厂商确认了什么事件、影响哪些组件 | /status 中同步的官方状态 |
| 独立 API 探测 | API 入口此刻能否连通、延迟多少 | /status，每 5 分钟从 Cloudflare 边缘探测，保留 30 天历史 |
| 用户报告 | 其他用户有没有遇到同类问题，是哪一类 | /down，按打不开、很慢、变笨了、限流、额度被重置、被登出分类报告 |
/down 把这三类信号放在同一页，例如 /down/chatgpt 和 /down/claude。只看 API 层面时，直接打开 /status/openai 或 /status/anthropic。探测方法和统计口径写在 /methodology。
三类信号组合起来，大致对应四种情况：
| 状态页 | 边缘探测 | 用户报告 | 最可能的解释 |
|---|---|---|---|
| 有事件 | 失败或变慢 | 集中出现 | 厂商侧故障，等恢复或切换备用 |
| 正常 | 失败或变慢 | 集中出现 | 厂商侧故障，状态页还没更新 |
| 正常 | 正常 | 集中出现 | 可能是某个地区、网络或账号层面的问题，或网页端与 API 表现不一致 |
| 正常 | 正常 | 只有你自己 | 先查自己的网络、密钥、额度和客户端配置 |
cdnping 的探测从 Cloudflare 边缘节点发起，只能说明“从海外网络到 API 入口是否通”，代表不了你本地的网络。要看自己这一段，可以用 cdnping 首页 的在线测速，测你的浏览器到各家 API 的首次连接（含 DNS 与 TLS 握手）和往返时间。
遇到“好像挂了”时按什么顺序排查？
第一步：在自己机器上确认现象
先分清是连不上、超时，还是返回了错误码。下面的命令不带密钥，不消耗额度，只看连通性和各阶段耗时：
# 查看 DNS 解析、TCP 连接、TLS 握手和首字节耗时
curl -o /dev/null -s -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s code=%{http_code}\n" https://api.openai.com/v1/models
curl -o /dev/null -s -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s code=%{http_code}\n" https://api.anthropic.com/v1/models
不带密钥时返回 401 是正常的，说明链路通了。如果卡在 connect 或 tls 阶段，或者 code 为 000，问题多半在网络链路。
第二步：读官方状态页的机器接口
厂商的状态页如果托管在 Statuspage 上，可以直接读 JSON，比打开页面快，也方便写进告警脚本：
# 把 <状态页域名> 换成对应厂商的官方状态页域名
curl -s https://<状态页域名>/api/v2/status.json | jq '.status'
curl -s https://<状态页域名>/api/v2/summary.json | jq '.components[] | {name, status}'
curl -s https://<状态页域名>/api/v2/incidents/unresolved.json | jq '.incidents[] | {name, status, impact}'
不是每家厂商都用 Statuspage，接口路径以各自状态页的说明为准。
第三步：对照独立探测和用户报告
打开 /status 看对应 API 的最近一次探测和 24 小时延迟分位，再打开 /down 看用户报告有没有集中出现。如果你遇到的问题状态页上没有，可以在 /down 一键报告，后来的人能更快判断。
第四步：按结果处理
- 厂商侧故障：停掉密集循环的重试，改成指数退避；有备用方案就切过去；到了
monitoring阶段再逐步恢复流量。 - 链路问题：检查本地网络、DNS 和代理设置。怀疑出口或分流有问题时，用 /ip 的 IP 与环境检测看出口 IP、DNS 泄漏和大陆分流情况。检测结果可以生成带水印的结果图，也可以先隐藏 IP 再发给同事。
- 只有你自己：检查密钥是否有效、额度是否用完、请求是否触发了限流（429）。
自建监控可以接哪些数据？
要把 AI 服务状态接进自己的告警，有三个现成的数据入口：
- cdnping 的开放数据
/api/status，采用 CC BY 4.0 协议，可以拉取各 API 入口的探测结果，引用时注明来源。 - /reports 的稳定性周报，每周一自动生成，可以订阅，适合做周度回顾，不适合当实时告警。
- 如果你用的是聚合网关，也要看网关自己公开的可用率。以 AGI Plan 为例（AGI Plan 是 cdnping 的商业合作方），它在
https://agiplan.dev/api/status/requests?month=YYYY-MM公开按小时、按能力组的成功与失败计数，不需要登录，默认返回 CSV，加format=json返回 JSON。cdnping 的 /status/agiplan 页面做了镜像展示。
告警规则可以以独立探测为主触发、状态页为辅助确认。例如连续两次探测失败就告警，告警内容附上状态页当前的 indicator 和进行中的事件名称，值班的人能马上看出是“厂商已知”还是“厂商还没发现”。
平时可以先把你依赖的组件列成一张表，每行写上对应的状态页条目和 cdnping 页面，出问题时照着上面四步走。
