ChatGPT is usually not working because of one of four failures: an OpenAI-side outage or capacity throttle, an expired or invalid session in your browser, a blocked network path (VPN, firewall, DNS, or corporate proxy), or a client-side fault such as a stale cache, full storage, or an outdated app. OpenAI publishes real-time status at status.openai.com, so checking there first separates “them” from “you” within seconds. Most individual reports resolve on OpenAI’s side; most persistent, repeatable failures are local. The sections below explain the mechanism behind each failure class, how to identify which one you are facing, and what actually fixes it.
What happens when you send a message
Every ChatGPT interaction is a chain of independent systems, and a failure anywhere in that chain produces a generic-looking error. Your browser or app first authenticates you with a session token. It then sends your prompt through a content delivery network to OpenAI’s API gateway. The gateway routes the request to a model inference cluster, which streams tokens back as they generate. Rate limiters, safety classifiers, and billing checks sit between the gateway and the model. Any one of these can reject a request, and the client often surfaces the same “Something went wrong” message regardless of which link broke.
The most common single point of failure is the session token. Tokens expire on a schedule, and they are bound to device and network fingerprints. If your IP address changes mid-session — common with mobile networks, VPNs, and public Wi-Fi — the server may treat the token as stolen and invalidate it. That produces a login loop or an immediate error even though your credentials are correct. Clearing cookies and signing in again rebuilds the token; it does not fix an OpenAI outage.
Streaming responses add a second failure mode. ChatGPT sends the answer incrementally over a long-lived connection. Corporate proxies, antivirus web shields, and some browser extensions buffer or terminate long connections. The result is a response that starts, stalls, or never renders even though the model generated text. A plain network test — loading a large file on the same connection — distinguishes a buffering problem from a model problem.
How often failures happen
OpenAI operates at very large scale, so even small failure rates produce many reports. Status incidents on status.openai.com are graded from degraded performance to partial outage to major outage, and most last minutes to a few hours. Peak-load windows track US business hours and weekday mornings, when request volume is highest; capacity throttles and “at capacity” messages cluster there.
Client-side causes dominate repeatable failures. A stale browser cache, an expired session, or a full message history each reproduce consistently, which makes them easy to misdiagnose as an outage. Device storage matters more than most people expect: the mobile apps cache conversations locally, and a nearly full phone slows or blocks sync. Error codes carry signal — a 401 or 403 points to authentication, 429 to rate limiting, 5xx to the server side — but the client often hides them behind generic text.
Accounts carry tiered rate limits. Free and paid plans differ in message caps and model access, and the caps reset on rolling windows rather than a fixed clock. Hitting a cap mid-conversation looks like an outage to the user but is a quota rejection. Checking plan status and the reset window resolves this class quickly.
Timeline of a typical OpenAI incident
| Stage | What you observe | Typical duration | What to do |
|---|---|---|---|
| Onset | Errors spike, new messages fail | Minutes | Check status.openai.com |
| Detection | Status page updates to investigating | 5–30 min | Wait; avoid repeated retries |
| Mitigation | Some models or regions recover first | 30 min–hours | Retry with a different model |
| Partial recovery | Intermittent errors, slow streaming | Hours | Reduce request frequency |
| Resolution | Status page marks resolved | — | Clear cache if errors persist |
| Residual | Stale session or cache faults remain | Minutes | Sign out, clear cookies, retry |
Timeline durations are qualitative ranges, not measured figures; actual incidents vary. The practical takeaway is that retrying aggressively during onset adds load and can extend your own throttling.
Edge cases that mimic outages
Several failures look identical to server outages but originate locally. A VPN exit node shared by thousands of users can be rate-limited as a single client, so requests fail for you while the service is healthy. A DNS resolver with a stale record routes you to a dead CDN node. A browser extension that injects scripts can break the streaming parser. Antivirus TLS inspection can terminate the encrypted connection mid-stream.
Red flag: every device on the same network fails, but mobile data works — suspect the network, router, or DNS. Red flag: a login loop after a password reset — suspect expired cookies or a conflicting session, not an outage. Red flag: responses stall at a fixed point every time — suspect a proxy, extension, or antivirus web shield. Red flag: errors only on one model — suspect capacity throttling or a model-specific incident. Red flag: “at capacity” during weekday mornings in the US — suspect peak load, not a bug.
Corporate networks add a specific layer. Many organizations block or inspect AI tools through a proxy. The block often returns a generic connection error rather than a clear policy message. Testing on a personal network is the fastest discriminator.
Misconceptions about ChatGPT failures
The most common misconception is that a deleted or “broken” account is the cause. Billing lapses and plan downgrades change access, but they produce specific paywall or upgrade prompts rather than silent failures. Another misconception is that clearing the app cache always fixes mobile errors; cache clears fix rendering faults but not authentication or quota faults.
A counterintuitive professional caveat: repeated rapid retries during an outage can trigger adaptive rate limiting on your account. Each retry counts against limits, and a burst of failed attempts may extend how long you are throttled after the service recovers. The correct behavior during a suspected outage is a slow, spaced retry, not a refresh loop.
Users also assume the desktop and mobile apps share state. They share account-level quotas but cache conversations independently. A fault can persist on one device and not another, which helps isolate the cause but misleads users into thinking the service is fine everywhere or broken everywhere.
Fixing it: practical actions in order
Work from most likely to least likely, and stop when the failure clears. Thresholds below are diagnostic, not guarantees.
Check status.openai.com first. If an incident is listed, stop troubleshooting locally and wait 15–30 minutes before retrying once. Force a fresh session. Sign out, clear cookies for the ChatGPT domain only, and sign back in. This fixes most login loops and 401/403 errors. Test a second network. Switch from Wi-Fi to mobile data or a different Wi-Fi. If the second network works, the fault is your router, DNS, proxy, or VPN. Disable the VPN or change exit node. Shared exit nodes are commonly rate-limited; a different node or no VPN resolves it. Clear the app cache and update the app. On mobile, a full phone accelerates this; check free storage and remove old downloads if the device is near capacity. Try a different model or start a new conversation. Model-specific incidents and long-context limits both produce failures that a new chat clears.
If all six steps fail and the status page is clean, the remaining causes are account-specific. Verify billing status and plan tier, then check for region-specific restrictions. Contact support with the error code, timestamp, and device — these three details cut resolution time sharply.
Comparison: where the fault usually sits
| Symptom | Likely cause | Layer | Fastest test |
|---|---|---|---|
| Login loop after sign-in | Expired or conflicting session | Client | Sign out, clear cookies |
| “At capacity” at peak hours | Server load or quota | OpenAI | Retry off-peak or check plan |
| Stalls mid-response | Proxy, extension, or antivirus | Network | New network or disable extension |
| Errors on one device only | App cache or storage | Client | Clear cache, free storage |
| All sites fail on one network | DNS, router, or firewall | Network | Mobile data test |
| 429 on many requests | Rate limit or retry burst | Account | Space retries, check plan |
| One model fails, others work | Model-specific incident | OpenAI | Switch model |
The table maps symptom to layer, which keeps you from fixing the wrong thing. A client-layer symptom cannot be solved by waiting for an outage, and a server-layer symptom cannot be solved by clearing cookies.
Limits of what this can tell you
No public source gives per-incident error rates or measured outage durations, so any precise percentage attached to ChatGPT failures is unreliable. Status pages report categories, not counts. Diagnosing without an error code is guesswork, which is why capturing the code and timestamp matters more than following generic checklists.
Model behavior also changes over time. Features, model names, and rate-limit structures shift, so advice tied to a specific interface can age out. The failure classes — authentication, network, client, quota, server — are stable; the menus and limits are not. When an official status update conflicts with forum reports, trust the status page first and treat anecdote as unverified.
This article is general educational information about troubleshooting software, not a guarantee of service availability or a substitute for OpenAI’s official support. For account, billing, or data concerns, contact OpenAI support or your organization’s IT administrator directly.