OpenAI status

How we check OpenAI

We watch api.openai.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We pin the exact response code the API's account root returns to an unauthenticated request rather than assuming any 2xx. An anonymous request to a modern API root is routinely rejected with an authentication error even when the service behind it is perfectly healthy, and a monitor that does not know that in advance reports every healthy day as an outage.

What is OpenAI?

OpenAI's API is the layer most AI-powered products actually call: a request goes out, a completion or embedding comes back, and the product built on top of it never has to run a language model itself. That makes the API a dependency in a very literal sense for a large and growing set of businesses, from a customer-support bot answering tickets to a coding assistant generating a diff to a background job summarizing documents in bulk.

What makes an OpenAI outage distinctive is how it fails. Because API calls are usually made server-side inside a longer request or job, a degradation does not look like a page that will not load, it looks like a request that times out, returns an error, or comes back slower than the rest of the product expects. In a synchronous flow, a user waiting on an AI-generated response can end up staring at a spinner. In an asynchronous one, a batch job can quietly fall behind and back up a queue that nobody notices until it is hours deep. Neither failure mode trips a typical uptime check the way a dead homepage would, which is part of why watching the API directly, rather than inferring its health from your own product's behavior, is worth doing.

Latency matters here in a way it does not for most APIs. A response that still eventually arrives but takes several times longer than usual can be just as disruptive to a product built around a fast conversational loop as an outright failure would be, since a chat interface with a ten-second delay reads as broken to most users even though, technically, nothing errored. That is why the response-time reading above is worth watching alongside the plain up-or-down state, not instead of it.

Incidents tend to be partial rather than total: a specific model degraded while others respond normally, or elevated error rates in one region while the rest of the API answers fine. If your integration is failing and the board above shows OpenAI healthy, the more likely explanations are an expired key, a rate limit you have hit, or a request shape that no longer matches what the current API expects.

Frequently asked questions

Is OpenAI down right now?

Check the board above; it reflects our own probes against the API, refreshed every couple of minutes from all five of our regions.

My app calling the OpenAI API is failing. Is that OpenAI's fault?

Only sometimes. A failing request can also mean an expired or rate-limited API key, a model name that changed, or a request payload that no longer matches the current API shape. If the board above shows OpenAI healthy, check your own error message and account dashboard before assuming an outage.

Does an OpenAI outage affect ChatGPT and the API at the same time?

Not necessarily. ChatGPT and the developer API share underlying infrastructure but are separate products with separate incident histories, a degraded API does not always mean a degraded ChatGPT and the reverse is also true. This page watches the API specifically, since that is what most integrations depend on.

How often does the OpenAI API actually go down?

Rarely for a full outage, more often for a partial degradation, elevated latency or errors on a specific model or region rather than every request failing. The uptime figures above are our own measured record rather than an estimate.