What to Do When OpenAI or ChatGPT Is Down

When ChatGPT or an OpenAI API feature fails, save the input and stop repeated submissions. The right next step depends on whether you are waiting for a browser answer, serving customers through an API or running an agent that can take actions.

Check the official OpenAI Status page and identify the affected product or feature. If there is no matching incident, use Is OpenAI down? to distinguish a service problem from a limit, credential issue or local connection failure.

Stop thrashing and preserve the task

Copy unsent prompts into a local note before refreshing or signing out. Save useful partial output, but label it unfinished. Record the error, time, model or feature and any request identifier available to you.

For an application, identify queued requests and automatic retries. Pause nonessential traffic if it is repeatedly failing. Keep a list of work whose completion is uncertain so it can be reconciled later rather than quietly submitted a second time.

For agents, inspect tool activity separately from the answer. A user may not receive the final response even though a file changed or an external operation completed. Do not equate “no answer” with “nothing happened.”

Confirm the scope and tell the team

Test one small harmless request in the affected product if a comparison is useful. Keep ChatGPT, API endpoints and individual features separate. A working browser chat is not a sufficient test of your production API path.

Use a concrete update:

OpenAI [product/feature] is affecting [workflow]. We observed [error] at [time and timezone]. The provider has [confirmed an incident / not published a matching incident]. We have paused [traffic or task]. Continue [available work]. [Owner] will update at [time].

If customers are affected, explain the interrupted action and whether their input is preserved. Avoid promising a restoration time without a reliable basis. Social posts and Downdetector can help corroborate symptoms, but do not turn them into a provider-confirmed diagnosis.

Keep working outside ChatGPT

For writing, create the outline, gather sources and mark questions that still need evidence. For coding, reproduce the issue, inspect the relevant files, write tests and review existing changes. You can prepare a better next prompt by clarifying what you already know.

If a task can be completed manually, finish it and record the result so a saved automation does not repeat it later. If it cannot, leave a concise handoff that includes the intended outcome, available inputs and what is still blocked.

Another approved model may help with a suitable task. Check access, data handling and actual availability before moving context. A fallback can have different behavior, so apply normal review and validation. The Claude outage playbook covers preserving work in that environment if it is also affected.

Handle API retries deliberately

OpenAI's error documentation distinguishes request, account-limit and server problems. Respect a retry delay when provided and bound retries for suitable transient failures. A permissions issue or exhausted allowance needs a different response from a temporary server error.

Inspect the retries already built into your SDK and job queue. Several layers retrying independently can create far more requests than the original workload. Use a clear maximum attempt count and a stopping point for the operation as a whole.

Keep user input and task identifiers stable across retries where your application supports that. For workflows that take external actions, verify completion at the destination before replaying them. A fresh generation is not a reliable way to discover whether an earlier tool call changed a record.

Handle partial answers and customer-facing failures

Check whether streamed output reached its expected completion. Do not store or display a truncated result as if it passed the same checks as a complete one. Preserve useful text only with its state made clear.

If generation is optional in your product, keep the rest of the workflow available and explain which feature is interrupted. If it is essential, give the user a clear failure state and a deliberate retry path rather than an endless spinner.

Do not introduce a new provider into production during the outage unless your team already has an approved, tested path. Capture the missing fallback as follow-up work. A hurried change in output format or tool behavior can create a second incident.

Recover one workflow at a time

An official recovery update is a reason to test the affected path. The status-page guide explains why broader status and your own results can differ.

1. Submit one small request using the affected product, model and application route.
2. Confirm completion, including stream handling and required output validation.
3. Inspect queued work and operations with uncertain results.
4. Reconcile external actions before retrying agent tasks.
5. Resume traffic gradually and watch errors, latency and queue progress.
6. Confirm that temporary failure messages and pauses are removed when appropriate.
7. Tell the team which workflows are verified and which still need attention.

Keep a short incident record with useful request identifiers and the exact failure mode. That evidence will help improve timeout handling, retries or customer messaging after normal service returns.

An optional break during the wait

Once the response is covered, join the Nines ping list for a tiny browser arcade that opens during qualifying official developer-tool outages. Degraded performance alone does not unlock it. It is optional downtime entertainment after the important work has an owner.