Is OpenAI down?
Filter to API components only on Starter and up.
OpenAI
operational
Last checked 17 Oct 2026, 06:06 UTC. Homepage reachable.
- Chat Completions
- Responses
- Agents
- Decisions
- Fine-tuning
- Embeddings
- Images
- Batch
- Audio
- Moderations
- Realtime
- Files
- Login
- Live
- Conversations
- Login
- ChatGPT Work
- Codex in ChatGPT Desktop
- Compliance API
- Search
- File uploads
- Voice mode
- GPTs
- Image Generation
No open incidents on the vendor status page.
Recent history
- Delayed Costs data in the Compliance API (resolved)
- Widespread feature degradation (resolved)
- Limited availability on gpt-image-2.5-flare and gpt-image-2.5-sunburst (resolved)
- Degraded performance in Codex and ChatGPT Work (resolved)
- Degraded performance in GPT-6.1 Sol Codex and Work mode (resolved)
- Delayed Costs data in the Compliance API (resolved)
- Some ChatGPT content may be unavailable on Android (resolved)
- Workspace admins may be unable to manage plugins (resolved)
The status panel shows what OpenAI's official status page currently reports. The API and ChatGPT are listed separately, and an incident can hit one without the other. If you build on the API, filter to the API components and ignore consumer app issues.
Outage or rate limit?
Many "OpenAI is down" moments are actually limits on your own account. Look at the error code first.
| Response | Likely meaning |
|---|
| 429 Too Many Requests | You hit a rate limit or your usage limit. Check the error message for which one. |
| 401 Unauthorized | Invalid, revoked or wrong-project API key. |
| 400 Bad Request | Something in the request is wrong, such as a model name that changed or a parameter not supported. |
| 500, 502, 503 | Server-side problems. If many requests fail this way, check the status page. |
| Timeouts | Could be load, long generations or network trouble. Compare against your normal response times. |
Also check your organization's usage limits and billing. An unpaid invoice or a reached spend limit looks like an outage from inside your app.
Partial incidents are common
AI APIs often have incidents that affect one model, one endpoint or one feature, such as higher error rates on a specific model, slower responses, or problems with file uploads. Your app might be fine on one model and failing on another. The incident text usually names what is affected.
Designing for AI provider outages
If your product depends on a model API, plan for the times it is slow or unavailable.
- Timeouts. Set sensible timeouts and show a friendly message rather than a spinner that never ends.
- Retries with backoff. Retry 5xx errors and timeouts with exponential backoff and jitter. Do not hammer the API during an incident.
- Fallback models. If a cheaper or older model is available, fall back to it for non-critical features.
- Fallback providers. Some teams keep a second provider configured for critical paths. This takes work, because prompts behave differently across models.
- Queues for background work. Summaries, tagging and other batch jobs can wait and catch up later.
- Feature flags. Let support switch off AI features quickly if they are causing user-facing errors.
Telling your users
If an AI feature is down, say so near the feature: "AI suggestions are temporarily unavailable." Users accept a missing feature better than a broken one. If it lasts more than a few minutes, post on your own status page.
Following OpenAI with Outage Clock
Add OpenAI to your vendor list and, on paid plans, pick only the API components. You get an alert when OpenAI posts an incident, each time it updates, and when it is resolved. Teams building on several AI providers can follow them all in one list and route alerts to the same channel.
Questions
Do you test the API with real requests?
We run a light reachability check against public endpoints. We do not send model requests or use your API key.
Is ChatGPT being down the same as the API being down?
Not necessarily. They are separate products and are listed separately on the status page.
Follow OpenAI