ChatGPT is up right now.
As of September 26, 2026, there are no reports of significant downtime. The service is operational and responding normally. UptimeRobot’s probes reached chatgpt.com and finished a full check without errors, the most recent automated run being September 24, 2026 at 19:53 GMT+0 from North America. Green dashboards everywhere.
Which is exactly when I want to talk about failure, because nobody writes fallback logic during an outage. They write angry posts.
A quick look at the year
2026 has handed bot builders a decent sample size. On February 4, users noticed something unusual and the reports started piling up. On July 25, Gulf News covered a global outage that hit users in the UAE and worldwide, with connectivity problems affecting the web app, the mobile app, and the developer APIs at the same time. On August 27, a shorter one, roughly 49 minutes. Then September 3, when ChatGPT and its coding sibling Codex went down for several hours in one of the largest disruptions OpenAI has logged this year, with the status page flagging elevated errors and outage trackers climbing past 74,000 reports.
The July event is the one I keep coming back to. Web, mobile, and API, together. If your architecture treats the API as a separate, sturdier thing than the consumer app, that day argues otherwise. Same upstream, same bad afternoon.
What actually breaks in your stack
Here is the part that surprises people the first time. The model endpoint going dark is rarely the worst of it. The worst of it is what your code does while waiting.
- Request pileup. Default timeouts are generous. A few hundred hanging requests exhaust your connection pool, and suddenly endpoints that have nothing to do with AI start returning 503.
- Retry storms. Naive retry loops turn one failed call into five, multiplying load against a service that is already struggling and burning your rate limits when it recovers.
- Half-written state. A multi-step agent that dies on step three of six leaves records in a shape no other part of your system expects.
- Silent queue loss. Background jobs fail, get marked as complete by an over-eager handler, and the work quietly vanishes.
- User confusion. A spinner that never resolves is worse than an honest error. People retry, duplicate submissions, and file support tickets.
The setup I run now
None of this is exotic. It is the same reliability thinking we have applied to payment gateways for twenty years, pointed at a model provider.
Short timeouts, real circuit breakers
Cap the call well below what feels comfortable. When failures cross a threshold, open the circuit and stop calling for a cooling-off window. Fail fast, fail cheap. During the September 3 event, systems without a breaker spent hours grinding through timeouts they could have skipped in seconds.
Retry with jitter, and a ceiling
Exponential backoff with randomized delay, three attempts maximum, and only for errors that are plausibly transient. A 400 does not get retried. Ever.
A second provider behind one interface
Write your calls against a thin internal abstraction so the model behind it is a config value. You do not need identical behavior from the backup, you need degraded-but-working. A smaller model that answers is worth more than a better model that is unreachable. Test the swap monthly or it will not work when you need it.
Queue everything you can
Move non-interactive work to a durable queue with visibility timeouts and a dead letter destination. Outages of 49 minutes become invisible to users when the work simply drains later.
Cache aggressively
Semantic caching on common prompts cuts cost on a normal Tuesday and keeps part of your product alive on a bad one. Cached answers are also the cheapest fallback you will ever ship.
Tell the truth in the UI
One clear message beats a frozen interface. Name the upstream issue, show what still works, offer to notify the user when the job finishes. Trust survives outages when communication does.
Instrument before you need it
Monitor your own error rates and latency percentiles rather than relying on a provider status page, which by nature lags the experience of your users. External trackers are useful for confirming you are not alone, but your dashboard should be the first to know. Log every fallback activation so you can see how often you are quietly running on plan B.
The Codex outage on September 3 matters for a specific reason. Coding tools are increasingly inside CI pipelines and developer workflows. When the model layer stops, builds stop too. Any automated step that calls a model needs a bypass path, or your release process inherits someone else’s incident.
Today the checks are clean and the trackers are quiet. That is the window. Spend an afternoon adding a timeout, a breaker, and a fallback, and the next outage becomes a line in your logs instead of a fire drill.
🕒 Published: