怎麼看 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 頁面，出問題時照著上面四步走。
