When ChatGPT or Claude is not working, check the status page for the product you use (status.openai.com, status.claude.com) before changing anything. Incidents often stay open an hour or more (medians: OpenAI 114 minutes, Anthropic 63; different windows, not a ranking). A silent OpenAI page does not rule out a service problem; we did not measure this for Claude.
Key takeaways
Key takeaways
- Match your symptom to a named component on your product’s status page. The page shows the provider has acknowledged a problem, not whether you are affected (our ChatGPT Work Mode case, where users kept failing after the page said recovered, read October 4, 2026).
- Read the incident title, not only the label. 6 of the 79 OpenAI incidents labelled degraded performance had titles using “down”, “unavailable” or “unable to”, such as “Image generation unavailable in ChatGPT” (our OpenAI incident study, retrieved October 8, 2026).
- Do not rule out a service problem because OpenAI’s page is silent. Across the 15 incidents we could match to OpenAI’s own post-incident reports (its “write-ups”), its first status post came a median of 20 minutes after the start the write-up gives (OpenAI only; the 15 skew toward serious incidents; we did not measure Claude).
- Treat “monitoring” and “resolved” as company words, not a user count. OpenAI’s write-up for September 29, 2026 dates residual degradation on some services to about 23:07 UTC, inside the page’s monitoring stage (19:39 to 23:14 UTC).
- Set a stop time before you wait (our untested rule). OpenAI’s incidents stayed open on the page a median of 114 minutes, and 48% (53 of 111) passed two hours.
- For Claude, read how many models the title names. Incidents naming multiple, many or all models had a median of 167 minutes on the page, against 30 for one model (11 incidents each; we sorted the titles).
Published October 11, 2026. Numbers come from our own datasets of OpenAI’s and Anthropic’s public status feeds, with retrieval dates in the sections below. Times are UTC. A status page records what a company posted, not user impact.
What to do when ChatGPT or Claude is not working: the five steps
Five checks, in order, take you from “is it just me?” to a decision:
- Check whether the problem is yours or the service’s.
- Read the status page for your product, words as well as label.
- Translate the status words.
- Estimate how long the incident will stay open, and set your own stop time.
- Choose: wait, re-test, or use another documented route.
The order is ours; the numbers come from our incident records, and we tested no fixes. Reading all five should take a few minutes (our estimate, not a measured result).
Step 1: Check whether the problem is yours or the service’s
Use the status page to learn whether the provider has acknowledged a problem; it cannot show whether you are affected. OpenAI’s page says availability may vary with subscription tier, model and API features (retrieved October 4, 2026, in our Work Mode case).
Start by repeating the same request on another device or network. That is generic advice, not from either provider and not tested by us; if it works there, the cause may be local. Then check the status page. If it lists an incident for your component, go to Step 2 and treat it as a known incident. If it lists nothing, go on anyway, because a quiet page does not rule out a service problem.
The cause is sometimes outside the provider, so read an incident’s update text for a named third party. If one is named, treat the Step 4 times as a poor guide: we have no duration data for third-party causes. Anthropic’s updates attribute the problem to a third party in at least 3 of 50 incidents by our phrase search (our Claude study, retrieved October 10, 2026). One was a four-day Claude Cowork bug on Windows, which Anthropic says a Microsoft fix closed.
We have no verified explanation of what any particular error message means, so do not treat an error message as a diagnosis.
Using Gemini instead? See Gemini “Something went wrong” codes and Gemini Live problems.
Step 2: Read the status page for your product, words as well as label
Match your symptom to a named component, such as Conversations or Codex on OpenAI’s page, or claude.ai or Claude Code on Anthropic’s. Then read the incident’s title as well as its label.
OpenAI labelled 79 of its 111 incidents (71%) degraded performance, yet six of those 79 have titles using “down”, “unavailable” or “unable to”, such as “Image generation unavailable in ChatGPT”. So the label alone can understate an incident. Some of the six are narrow, such as “Users unable to login to ads manager”, so read the title for scope (our OpenAI incident study, retrieved October 8).
A page’s first post can also come after the start a write-up gives. OpenAI links a write-up from 17 of its 111 incidents. In the 15 we could match to a single impact window, the first status post came after the write-up’s stated start, by a median of 20 minutes (range 7 to 75; write-ups retrieved October 6 to 8, 2026; our status-page comparison).
Two limits apply. The 15 skew toward serious incidents, and late posting is not a rule: one of the two incidents we left out (their write-ups describe more than one impact period) was posted before its write-up’s “most significant impact”. The figure is OpenAI only, and we did not measure Claude’s page.
Users can also still fail after the page says service has recovered. On September 14, 2026, 11 forum users reported Work Mode failures between 17:08 and 19:34 UTC, after OpenAI’s first update (15:58 UTC) said service had recovered (unverified user reports; retrieved October 4, 2026; the case).
Step 3: Translate the status words
None of the eight terms below gives a count of affected users. Four are stage words, three are status labels and one is the uptime figure, in that order.
The stage words are paraphrased from Atlassian’s incident-communication guide (retrieved October 5, 2026) and the labels from Atlassian’s component documentation (retrieved October 11, 2026). The Uptime row follows incident.io’s uptime documentation (retrieved October 10, 2026).
Anthropic’s page runs on Atlassian Statuspage and OpenAI’s on incident.io. We did not find incident.io’s definitions of the statuses, or OpenAI’s own, so Atlassian’s wording is an assumed fit for OpenAI. The table’s stage counts come from our October 5 to 6 snapshot of OpenAI’s 21 and Anthropic’s 50 incidents.
| Word | What it means (source) | What we measured | Read more |
|---|---|---|---|
| Investigating | Atlassian: the company has been alerted and is looking into a potential problem. | 40 of Anthropic’s 50 incidents and 10 of OpenAI’s 21 were first posted here: a common first word, not a sign of size. | Stage study |
| Identified | Atlassian: the company announces that it has identified a problem. (Our gloss: that is not a fix.) | 10 of OpenAI’s 21 and 8 of Anthropic’s 50 were first posted here, so a first post can already say identified. | Stage study |
| Monitoring | Atlassian: the company thinks it has found a solution and is monitoring it. | Median 32 minutes (OpenAI) and 25.5 (Anthropic) from first monitoring update to resolved, in different sets of incidents (not a ranking). OpenAI’s September 29, 2026 write-up dates residual degradation to about 23:07 UTC, inside this stage. | Stage study |
| Resolved | Atlassian: the company says it has resolved the incident. | 29 of the 71 incidents (21 OpenAI and 50 Anthropic) closed with no monitoring update. In the Work Mode case, three forum users reported recovery about seven hours before the page closed (unverified). | Stage study |
| Degraded performance | Atlassian: the component is working but is slow or otherwise impacted in a minor way. | 79 of OpenAI’s 111 incidents carry it. Uptime counts it as zero downtime (incident.io lists it as “up”). | 111 incidents |
| Partial outage | Atlassian: the component is completely broken for a subset of customers. | 12 of OpenAI’s 111 incidents. Atlassian’s uptime page discounts partial outage to 30% as bad as major outage; incident.io lists it as “down” with no weighting (retrieved October 10). OpenAI’s published uptime figures nonetheless fit a 30% weighting in our Uptime study rebuild. | 111 incidents |
| Major outage | Atlassian: the component is completely unavailable. (OpenAI’s feed says “full outage”.) | 2 of OpenAI’s 111 incidents. Uptime counts it in full. | 111 incidents |
| Uptime | incident.io: the share of time a component is in a status counted as “up”; full and partial outage count as “down” and degraded performance as “up”. | OpenAI’s ChatGPT group showed 99.52% but Conversations alone 99.91% (a window we read as the 90 days to October 10, 2026), so check the figure for the component you use. | Uptime study |
Step 4: Estimate how long it will stay open, and set your own stop time
OpenAI’s 111 incidents stayed open a median of 114 minutes (July 10 to October 8, 2026), and Anthropic’s 49 resolved incidents a median of 63 minutes (July 27 to October 7). Retrieved October 8 and 10; see our OpenAI incident study and our Claude study.
These are minutes on the page, from the start it shows to the first “resolved” update, monitoring included. They are not your downtime and cannot forecast your incident. The windows and labelling rules differ, so the medians are not a ranking (for why raw incident counts mislead, see our September 2026 count comparison).
On Claude’s page the title is a rough guide (small groups, and we sorted the titles). Incidents whose titles name one model had a median of 30 minutes (11 incidents) and those naming two or three models 80 (7 incidents). Titles saying multiple, many or all models had a median of 167 minutes (range 26 to 429), and 7 of 11 passed two hours. None of the 18 incidents naming one, two or three models passed two hours (the longest was 95 minutes), but that is page time only: one single-model incident (August 14) was open 30 minutes on the page, while its resolved note gives about four hours of impact.
A planning rule of ours, untested: count from the start time the incident shows, and set your stop time before you start waiting, using the page-open median for your case:
- OpenAI: about two hours (median 114 minutes, 111 incidents).
- Claude, title names one model: about 30 minutes (11 incidents).
- Claude, title names two or three models: about 80 minutes (7 incidents).
- Claude, title names multiple, many or all models: about 167 minutes (11 incidents).
- Claude, title names no model: about 63 minutes (all 49 resolved incidents; a fallback).
Step 5: Choose: wait, re-test, or use another documented route
Find your situation in the table and take the action in its last column. Rows 1 to 3 follow what the page shows; rows 4 and 5 are special cases.
Only incident length, and for OpenAI the lag of its first post, have numbers behind them. The other choices rest on single incidents or small samples, so use them only when the incident’s own text supports them. Re-test when the page changes stage or your stop time arrives (our judgement, untested).
| Situation | What the evidence supports | Action |
|---|---|---|
| The page lists an open incident for your product. | Page-open time for your case (Step 4). | Plan to check the page again at your stop time, then find your row again. |
| The page lists nothing and your errors continue. | For OpenAI, the first post came after the stated start in 15 of 15 matched incidents, median 20 minutes (our status-page comparison), so a silent page does not rule out a service problem. We did not measure Claude’s page. | Check the page again; if it is ChatGPT, re-test as well. |
| The page says monitoring or resolved, but you still fail. | OpenAI’s September 29, 2026 write-up dates residual degradation to about 23:07 UTC, inside the page’s monitoring stage (September 29). | Re-test a small request (or your error rate, if you run jobs) before restarting anything. |
| You may be able to reach the service another way. | Incident-specific only: OpenAI’s September 25, 2026 Codex write-up says access with customer-provided API keys was unaffected while sign-in with ChatGPT failed (write-ups review). | Use another route only if that incident’s own text says it was unaffected. During a live incident that text may not exist yet, because write-ups can arrive days later, so default to waiting or re-testing. |
| Several services fail at once. | On September 3, 2026, a news report we read suggested an Azure outage, while OpenAI’s write-up named its own routing change (the Azure check). | Read each company’s own incident page before accepting one shared explanation, then wait or re-test as above. |
Write-ups are scarce: 17 of 111 OpenAI incidents (15%) link one, and two share a write-up, so there are 16 distinct (retrieved October 8, 2026). The September 29 write-up was linked between about seven and eight days after the incident (retrieved October 6 and 7).
In short, our untested rule: wait to your stop time, re-test when the stage changes, and use another route only if the incident’s own text says it was unaffected. At your stop time the choice is yours: our data cannot say whether retrying, switching route or contacting support helps, and the table lists only what individual incidents’ own text supports.
If you are still failing at your stop time, check the page’s current stage and find your row again. The one escalation we can point to is the support case OpenAI Support asked still-affected users to open in the Work Mode thread (September 16, 2026): one incident, the effect unknown, and no Anthropic equivalent.
If you build on the API or run jobs nobody watches
A “mitigation applied” update does not by itself mean recovery. OpenAI’s write-up for September 29, 2026 dates residual degradation on some services to about 23:07 UTC, more than three hours after the status page said “mitigation applied” at 19:39 UTC (retrieved October 7, 2026; the September 29 comparison). Our reading: watch your own error rate before restarting batch jobs or agents (Step 5).
OpenAI’s September 29, 2026 write-up says some Agents API requests failed, while other write-ups say the API Platform was unaffected: read each incident’s own text.
What we could not verify
The limits of this article’s evidence are:
- Page times are not user impact, and we have no independent error measurements or verified explanations of particular error messages.
- We did not measure Anthropic’s page delay.
- The Claude title groups are small (7 to 11 incidents), and the no-model figure is the overall median, a fallback. They are our reading of titles that Anthropic’s staff write and can edit, and we did not recompute them on stated impact windows.
- Our OpenAI data ends October 8 and Anthropic’s October 7, and each feed holds only recent incidents, so the latest days and earlier months are missing.
- We tested no fixes (retries, cache clearing, VPNs, devices).
- The API-key route, the support-case request and the Windows update are single incidents, not rules.
Where the numbers come from
Methods and downloadable data are in:
- OpenAI’s 111 incidents
- Claude’s 50 incidents
- status-page accuracy (15 write-ups)
- what “resolved” means
- the uptime rebuild
Primary sources:
- status.openai.com and status.claude.com
- Atlassian’s incident-communication guide (retrieved October 5, 2026)
- Atlassian’s component documentation (retrieved October 11, 2026)
- Atlassian’s historical-uptime documentation (retrieved October 10, 2026)
- incident.io’s uptime documentation (retrieved October 10, 2026)
Frequently asked questions
Set a stop time before you start waiting (our planning rule, untested): two hours for OpenAI, whose 111 incidents stayed open a median of 114 minutes. For Claude, use about 30 minutes if the title names one model, about 80 for two or three, about 167 for multiple, many or all, and about 63 if it names none (our Claude study; different window, not a ranking). That is page time, not downtime.
Degraded performance, in Atlassian’s definition, means the component is working but slow or otherwise impacted in a minor way. 6 of the 79 OpenAI incidents carrying the label have titles using “down”, “unavailable” or “unable to” (our OpenAI incident study). We did not find OpenAI’s own definition, and uptime counts the label as zero downtime.
A silent page does not rule out a service problem. OpenAI’s first status post came a median of 20 minutes after the start in its write-up, across 15 matched incidents that skew serious (our status-page comparison). The figure is OpenAI only, and we did not measure Claude’s page.
Re-test a small request before restarting anything: neither word counts affected users (what resolved means). OpenAI’s September 29, 2026 write-up dates residual degradation to a time inside the page’s monitoring stage.
