What happens to your multi-agent system when the model stops answering mid-task? Not when it returns a bad answer, not when it hallucinates a function signature, but when the socket just hangs and the token stream dies at step four of a nine-step plan. Most teams I talk to can describe their prompt strategy in detail and cannot describe that failure path at all.
The question is timely because, right now, nothing is broken. As of September 26, 2026, there are no reports of significant ChatGPT downtime. The service is operational and responding normally. UptimeRobot’s probes reached chatgpt.com and completed a full check without errors, the most recent automated run coming from North America on September 24, 2026 at 19:53 GMT. Status trackers report no current problems. The last detected outage was Thursday, August 27, 2026, lasting roughly 49 minutes.
Which is exactly why this is the right moment to think about it. Nobody designs failure handling during a failure.
A year of interruptions, not a single catastrophe
Look at 2026 as a pattern rather than a set of incidents. On February 4, users noticed unusual behavior accessing ChatGPT. On July 25, Gulf News reported 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 simultaneously. On September 3, ChatGPT and its coding sibling Codex went down for several hours in one of the largest disruptions OpenAI logged this year, with OpenAI’s status page flagging elevated errors and outage trackers climbing past 74,000 reports. Then the 49-minute event on August 27.
Two things stand out to me as an architecture problem rather than a reliability story.
First, the July 25 event took the web app, the mobile app, and the API together. That correlation matters enormously for anyone building on top of these systems. If your fallback plan for an API failure is “the team can use the chat interface manually,” you have not built a fallback. You have built two clients pointed at the same dependency.
Second, the September 3 event took Codex down alongside ChatGPT. Your coding agent and your conversational agent are not independent vendors in a diversified portfolio. They are neighbors sharing a wall.
What actually breaks in agent systems
A single chat turn failing is a minor annoyance. A user retries. But agent architectures convert a transient fault into something considerably worse, for reasons that are structural.
- Partial state. An agent that has already written three files, opened a pull request, and sent a Slack message is not in a retryable position. Restarting the plan from scratch duplicates side effects. Resuming requires that you serialized enough state to know where you were, and most frameworks serialize the conversation, not the consequences.
- Retry storms. Naive exponential backoff across hundreds of concurrent agent loops turns a degraded provider into a hammered one. Your system becomes part of the incident.
- Cascading planners. When an orchestrator calls a sub-agent that calls a tool that calls a model, a timeout at the leaf propagates as an ambiguous error at the root. The planner then reasons about a failure it cannot see clearly, and often decides to try something creative.
- Silent degradation. Elevated errors are not a binary. Some calls succeed slowly. An agent with a 30-second tool timeout and a 90-second model response is experiencing an outage that no status page will confirm for it.
Designing for a provider that will be gone sometimes
The useful framing is not “how do I avoid downtime” but “what does my system do for 49 minutes without a model.” A few patterns I keep recommending.
Make the plan durable, not the conversation
Persist the task graph, the completed steps, and the observed side effects to durable storage outside the agent process. On resume, replay from the last confirmed effect, not the last message. Idempotency keys on every external action are the unglamorous prerequisite here.
Treat model choice as configuration
Route through an abstraction where the provider is a runtime decision. This is harder than it sounds because prompts are coupled to model behavior, tool-calling formats differ, and your evaluation suite probably only covers the primary. The work is in maintaining a tested secondary path, not in writing the router.
Define an explicit degraded mode
Decide in advance which tasks pause and which fail loudly. A background summarization job can queue for an hour. An agent holding a database migration halfway through cannot. Classify your workflows by their tolerance for suspension and enforce it in code.
Instrument latency, not just errors
Track time-to-first-token and full-completion distributions per step. Slow is the more common failure, and it is the one that silently breaks timeout assumptions deep in a call chain.
The intelligence in an agent system is mostly borrowed. The reliability has to be yours. Right now, with everything green and probes passing cleanly, is the cheapest time you will ever have to build it.
đź•’ Published: