---
title: "怎么看 OpenAI 状态页和 Claude 状态页：事件等级、组件与真实影响"
description: "OpenAI 状态页和 Claude 状态页上的 none、minor、major、critical 各代表什么？本文讲清组件状态、事件阶段和状态页滞后的原因，并给出结合 API 探测与用户报告的排查步骤。"
url: https://cdnping.org/blog/how-to-read-ai-status-pages
language: zh-CN
published: 2026-10-17
category: "服务动态"
tags: ["状态页","AI 服务状态","OpenAI","Claude","故障排查"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# 怎么看 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`。窗口只有一个多小时，不能据此说这个服务不稳定，但它说明了一个常见情况：少量失败往往达不到厂商登记事件的门槛。

## 状态页显示正常，为什么我还是连不上？

状态页有几处固有的盲区：

1. 滞后。事件要人工确认后才发布，故障开始到出现 `investigating` 之间通常有一段空档。
2. 门槛。只影响少数用户、少数地区或某类账号的问题，可能不会被登记。
3. 视角单一。状态页反映的是厂商内部监控，看不到你的网络到 API 入口之间的链路。从中国大陆访问海外 API 时，不少“连不上”就发生在这一段，厂商状态页不会显示。
4. 粒度粗。组件划分由厂商决定，不一定细到你用的那项能力。
5. 体验类问题不在上面。“回答质量变差”“额度突然被重置”“被登出”这类问题，一般不会出现在状态页上。

## 怎样用 API 探测和用户报告交叉验证？

三类信号各自回答不同的问题：

| 信号 | 回答的问题 | cdnping 对应页面 |
|---|---|---|
| 官方状态页 | 厂商确认了什么事件、影响哪些组件 | [/status](/status) 中同步的官方状态 |
| 独立 API 探测 | API 入口此刻能否连通、延迟多少 | [/status](/status)，每 5 分钟从 Cloudflare 边缘探测，保留 30 天历史 |
| 用户报告 | 其他用户有没有遇到同类问题，是哪一类 | [/down](/down)，按打不开、很慢、变笨了、限流、额度被重置、被登出分类报告 |

[/down](/down) 把这三类信号放在同一页，例如 [/down/chatgpt](/down/chatgpt) 和 [/down/claude](/down/claude)。只看 API 层面时，直接打开 [/status/openai](/status/openai) 或 [/status/anthropic](/status/anthropic)。探测方法和统计口径写在 [/methodology](/methodology)。

三类信号组合起来，大致对应四种情况：

| 状态页 | 边缘探测 | 用户报告 | 最可能的解释 |
|---|---|---|---|
| 有事件 | 失败或变慢 | 集中出现 | 厂商侧故障，等恢复或切换备用 |
| 正常 | 失败或变慢 | 集中出现 | 厂商侧故障，状态页还没更新 |
| 正常 | 正常 | 集中出现 | 可能是某个地区、网络或账号层面的问题，或网页端与 API 表现不一致 |
| 正常 | 正常 | 只有你自己 | 先查自己的网络、密钥、额度和客户端配置 |

cdnping 的探测从 Cloudflare 边缘节点发起，只能说明“从海外网络到 API 入口是否通”，代表不了你本地的网络。要看自己这一段，可以用 [cdnping 首页](/) 的在线测速，测你的浏览器到各家 API 的首次连接（含 DNS 与 TLS 握手）和往返时间。

## 遇到“好像挂了”时按什么顺序排查？

### 第一步：在自己机器上确认现象

先分清是连不上、超时，还是返回了错误码。下面的命令不带密钥，不消耗额度，只看连通性和各阶段耗时：

```bash
# 查看 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，比打开页面快，也方便写进告警脚本：

```bash
# 把 <状态页域名> 换成对应厂商的官方状态页域名
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](/status) 看对应 API 的最近一次探测和 24 小时延迟分位，再打开 [/down](/down) 看用户报告有没有集中出现。如果你遇到的问题状态页上没有，可以在 /down 一键报告，后来的人能更快判断。

### 第四步：按结果处理

- 厂商侧故障：停掉密集循环的重试，改成指数退避；有备用方案就切过去；到了 `monitoring` 阶段再逐步恢复流量。
- 链路问题：检查本地网络、DNS 和代理设置。怀疑出口或分流有问题时，用 [/ip](/ip) 的 IP 与环境检测看出口 IP、DNS 泄漏和大陆分流情况。检测结果可以生成带水印的结果图，也可以先隐藏 IP 再发给同事。
- 只有你自己：检查密钥是否有效、额度是否用完、请求是否触发了限流（429）。

## 自建监控可以接哪些数据？

要把 AI 服务状态接进自己的告警，有三个现成的数据入口：

- cdnping 的开放数据 `/api/status`，采用 CC BY 4.0 协议，可以拉取各 API 入口的探测结果，引用时注明来源。
- [/reports](/reports) 的稳定性周报，每周一自动生成，可以订阅，适合做周度回顾，不适合当实时告警。
- 如果你用的是聚合网关，也要看网关自己公开的可用率。以 AGI Plan 为例（AGI Plan 是 cdnping 的商业合作方），它在 `https://agiplan.dev/api/status/requests?month=YYYY-MM` 公开按小时、按能力组的成功与失败计数，不需要登录，默认返回 CSV，加 `format=json` 返回 JSON。cdnping 的 [/status/agiplan](/status/agiplan) 页面做了镜像展示。

告警规则可以以独立探测为主触发、状态页为辅助确认。例如连续两次探测失败就告警，告警内容附上状态页当前的 indicator 和进行中的事件名称，值班的人能马上看出是“厂商已知”还是“厂商还没发现”。

平时可以先把你依赖的组件列成一张表，每行写上对应的状态页条目和 cdnping 页面，出问题时照着上面四步走。