ChatGPT failing in your browser does not establish that the OpenAI API is down. An API request failing in your application does not establish that ChatGPT is unavailable. Begin with the product and operation you were actually using.
Open the official OpenAI Status page, then read the component and incident notes. Use that page for current provider updates. This article explains how to investigate symptoms and does not present an automatically refreshed availability verdict.
Is ChatGPT down for everyone or just my session?
Save any unsent prompt before refreshing. Note whether you can load the site, sign in, open an existing conversation and submit a short new request. These are separate tests, and success at one does not guarantee success at the next.
Ask a colleague to test the same feature with their own account if appropriate. Compare the model or feature involved. A working short text conversation does not test a failed file upload or another generation mode.
If only your session fails, compare a different supported browser or permitted network after preserving your work. Do not clear every cookie and extension setting at once. A useful diagnosis tracks one changed variable and its result.
Which symptom points to which check?
| Symptom | What to compare |
|---|---|
| Login fails | Session, account, network and login incident scope. |
| Existing chats load but new answers fail | Generation, model and feature-specific errors. |
| One conversation behaves differently | Conversation inputs and a small clean comparison. |
| Application receives API errors | Endpoint, response body, project and credentials. |
| A response begins and then stops | Stream completion, client connection and error events. |
Use this table to choose a check, not to infer a cause from a single screenshot. Keep any request identifier and the exact error wording. Remove private prompts, authorization headers and personal details from public reports.
Is an API 429 response an outage?
Not by itself. OpenAI's API error reference distinguishes rate and usage-limit errors from server failures. Read the response body: the same broad HTTP status can require different action depending on the stated limit or error code.
Check which project and organization your application intended to use. A shared account limit can affect several developers without implying that all customers are affected. Repeating the same request faster is not a useful test of that distinction.
Authentication and permission failures also deserve their own investigation. Verify the intended credential and environment without printing secrets into logs. Do not rotate keys or change spending settings merely because a request failed during a period when other users are complaining.
How do I tell an application bug from an API problem?
Follow one failed request through your application. Did it reach the provider, receive an error or fail earlier in your server? Check the endpoint, selected model, timeout and request identifier. Preserve enough context to compare another attempt without storing unnecessary sensitive input.
Try a small known-valid request through the same route if you can do so safely. If that works, compare the original input and feature requirements. If it fails the same way across authorized environments, that is stronger evidence of a shared dependency problem.
Do not use a production action with external effects as a health check. An assistant that sends messages or changes records needs a harmless test path. A lost response cannot tell you whether the external tool completed its action.
What if a response stops midway?
Treat the result as incomplete until your application has confirmed completion. A visible paragraph or initial successful connection does not guarantee that the whole response arrived. Preserve partial work with that limitation clear.
Check client and server logs around the disconnect. Compare whether a short request completes and whether the failure repeats only with longer work. Avoid drawing a platform-wide conclusion from a single request that exceeded your application's own timeout.
If the workflow used tools, inspect the resulting records or files before retrying it. An interrupted generation and an interrupted tool execution are separate states. Starting the entire task again can duplicate work even if the original answer never reached the user.
What does a partial OpenAI outage mean?
Read the incident description for the affected product, feature or model. A failure affecting one route can coexist with successful requests elsewhere. Your team's workflow may be completely blocked even though another customer's short chat works normally.
Do not generalize between ChatGPT and API access, or between different models and features. If a fallback is available, verify it through the route you plan to use rather than assuming a different button means a different dependency.
The shared status-page guide explains why a green summary can disagree with a particular account, region or request. An incident label is evidence about reported scope, not a substitute for testing your own workflow.
How much weight should public reports carry?
Downdetector and social posts can reveal similar complaints at the same time. They do not establish the root cause, and reports about ChatGPT cannot automatically diagnose your API integration. Check timestamps and the precise feature being discussed.
Use official updates for acknowledged incident scope and your logs for local impact. Once a provider issue looks likely, follow the OpenAI outage playbook. Stop repeated submissions, preserve unfinished work and verify one representative request before restoring normal traffic.