Blog / Service updates

How to Read OpenAI and Claude Status Pages: Levels & Components

2026-10-17cdnping editors10 min read

An OpenAI or Claude status page tells you what the vendor has confirmed, not whether you can use the service right now. Read the page-level indicator first, then the component you actually depend on, then the stage the incident is in. Only when all three line up can you say whether an outage affects you. Incidents are published after a human confirms them, so they often appear later than the failure actually began. That is why you should also compare against independent API probes and user reports. A checklist you can follow step by step is at the end.

#What do the green, yellow, orange and red banners at the top mean?

Many AI vendors host their status pages on Atlassian Statuspage or use a similar data structure. Taking Statuspage as the example, the line at the top of the page, either "All Systems Operational" or a colored banner, maps to the status.indicator field in the API. It has five common values (the colors are the default theme, and vendors can customize them):

Two things are easy to misread.

First, the top-level indicator reflects the single worst current problem. If a minor and a major incident are open at the same time, the banner shows major. If that major incident only affects image generation and you only call the text endpoints, you may not be affected at all.

Second, vendors set the levels themselves, so they are not comparable across vendors. For the same "some users see errors" situation, one team files minor and another files major. The data below shows how different the distributions are.

#Which component should I look at?

The second layer of a status page is components. AI vendors often split their service into the web app, the API, individual product lines, the console, login, billing and so on, each with its own status:

The most common mismatch developers hit is the chat web app having problems while the API is fine, or the reverse. So first work out which components your call chain depends on, for example:

• Calling the API with an official SDK: look at the API component, plus the component for the capability you use (text, image, voice, files and so on).
• Using a command-line coding tool: besides the API, check the tool's own component and the login and auth components.
• Only chatting in the web app: look at the web app and login components.

Component status and incident level are two separate fields. One incident can be linked to several components. The incident's impact is one of none, minor, major or critical, while a component's status is one of the five values in the table above. When judging blast radius, component status is more specific than the incident title.

#What should I do at each stage, from investigating to resolved?

The standard incident stages on Statuspage are:

Planned maintenance has its own stages: scheduled, in_progress, verifying and completed.

During monitoring, do not restore all your traffic at once. Let a small share through first and watch the error rate. If you still see errors after resolved, check your client cache, connection pool and your own network path first.

#Can incident levels be compared across status pages?

No. cdnping syncs the official status pages of OpenAI, Anthropic, Moonshot, Groq, Cloudflare, GitHub and Cursor every 15 minutes. The table below counts incidents synced from those pages by incident impact over the window 2026-09-17 to 2026-10-17 (source: each official status page, aggregated by cdnping). cdnping only started collecting on 2026-10-17, so this month of data comes from the history the status pages themselves retain, not from long-term cdnping observation.

A few things stand out from the table:

• More incidents does not mean less stable. 19 of OpenAI's 25 incidents are minor, which may suggest it tends to log even localized problems. The Claude status page has few incidents in total, but 6 of its 8 are marked major. These numbers mostly reflect logging habits and should not be compared directly as availability.
• The same level carries different weight at different vendors. All 8 Moonshot incidents in the window are marked critical, with no lower-level records. So do not treat the count of critical incidents as a stability ranking.
• Incident times are not always accurate. Among the latest 40 incidents cdnping synced, 7 have a negative duration when computed as resolved time minus created time. GitHub also has incidents whose titles carry "[Retroactive]", meaning they were back-filled after the fact. Start and end times on a status page are good for rough orientation, not for precise downtime calculations.

Here is an example of a status page showing normal while probes still saw failures. In cdnping's edge probe snapshot from 2026-10-17 UTC 08:40 to 10:05 (Cloudflare Denver node, 242 probes covering 15 API endpoints), the Moonshot API endpoint had a 94.4% success rate, while its official status page indicator at the same time was none. The window is only a bit over an hour, so you cannot conclude the service is unstable from it, but it illustrates a common situation: a small number of failures often falls below the threshold for a vendor to log an incident.

#The status page says normal. Why can't I connect?

Status pages have several built-in blind spots:

1. Lag. Incidents are published after human confirmation, so there is usually a gap between when a failure starts and when investigating appears.
2. Thresholds. Problems affecting only a few users, a few regions or one type of account may never be logged.
3. A single viewpoint. The status page reflects the vendor's internal monitoring and cannot see the path between your network and the API endpoint. When accessing overseas APIs from mainland China, many "can't connect" cases happen on that segment, and the vendor's status page will not show them.
4. Coarse granularity. The vendor decides how components are split, and they may not be fine-grained enough to cover the specific capability you use.
5. Experience issues are not covered. Problems like "answer quality got worse", "my quota was suddenly reset" or "I got logged out" generally do not appear on status pages.

#How do I cross-check with API probes and user reports?

The three kinds of signal each answer a different question:

/down puts all three signals on one page, for example /down/chatgpt and /down/claude. To look only at the API layer, open /status/openai or /status/anthropic directly. The probing method and statistical definitions are written up in /methodology.

Combined, the three signals map roughly to four situations:

cdnping probes from Cloudflare edge nodes, so it can only tell you whether the API endpoint is reachable from an overseas network. It cannot represent your local network. To check your own segment, use the live speed test on the cdnping home page, which measures your browser's first-connection time to each API (including DNS and TLS handshake) and round-trip time.

#What order should I follow when something seems to be down?

#Step 1: Confirm the symptom on your own machine

First tell apart a failed connection, a timeout and an error code in the response. The commands below carry no key and use no quota; they only check connectivity and the time spent in each phase:

# Show DNS resolution, TCP connect, TLS handshake and time-to-first-byte
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

A 401 without a key is normal and means the path works. If it stalls at connect or tls, or the code is 000, the problem is most likely in the network path.

#Step 2: Read the status page's machine interface

If the vendor's status page is hosted on Statuspage, you can read the JSON directly. It is faster than opening the page and easy to wire into an alerting script:

# Replace <status-page-domain> with the vendor's official status page domain
curl -s https://<status-page-domain>/api/v2/status.json | jq '.status'
curl -s https://<status-page-domain>/api/v2/summary.json | jq '.components[] | {name, status}'
curl -s https://<status-page-domain>/api/v2/incidents/unresolved.json | jq '.incidents[] | {name, status, impact}'

Not every vendor uses Statuspage; follow each status page's own documentation for the API path.

#Step 3: Compare against independent probes and user reports

Open /status to see the latest probe for the relevant API and the 24-hour latency percentiles, then open /down to see whether user reports are clustering. If the problem you're hitting is not on the status page, you can file a report on /down in one click, which helps whoever comes next judge faster.

#Step 4: Act on the result

• Vendor-side outage: stop tight retry loops and switch to exponential backoff; switch to a fallback if you have one; restore traffic gradually once the incident reaches monitoring.
• Path problem: check your local network, DNS and proxy settings. If you suspect a problem with your egress or traffic routing, use the IP and environment check at /ip to see your exit IP, DNS leaks and how traffic is routed relative to mainland China. The result can be exported as an image with a watermark, or you can hide the IP first before sending it to a colleague.
• Only you: check that your key is valid, your quota is not used up and your requests did not trigger rate limiting (429).

#What data can I plug into my own monitoring?

There are three ready-made data sources for wiring AI service status into your own alerting:

• cdnping's open data at /api/status, licensed under CC BY 4.0. You can pull probe results for each API endpoint; please credit the source when you use it.
• The weekly stability reports at /reports, generated automatically every Monday and available by subscription. They suit weekly reviews, not real-time alerts.
• If you use an aggregating gateway, also look at the availability the gateway itself publishes. Take AGI Plan as an example (AGI Plan is a commercial partner of cdnping). It publishes hourly success and failure counts by capability group at https://agiplan.dev/api/status/requests?month=YYYY-MM, with no login required. It returns CSV by default, or JSON with format=json. cdnping's /status/agiplan page mirrors it.

For alert rules, use independent probes as the primary trigger and the status page as secondary confirmation. For example, alert after two consecutive probe failures, and include the status page's current indicator and the names of open incidents in the alert, so the on-call person can immediately tell whether it is "known to the vendor" or "not yet noticed by the vendor".

A good habit is to list the components you depend on in a table, with the matching status page entry and cdnping page on each row, and then follow the four steps above when something breaks.