ChatGPT and Codex Suffer Sudden Outage

ChatGPT and Codex Experience Simultaneous Outages

On July 25, OpenAI suffered a sudden, large-scale service outage. Many users reported that both ChatGPT and Codex were unavailable, with common symptoms including login failures, request errors, interrupted conversations, and prolonged service unresponsiveness.

Reports of OpenAI issues on the third-party outage monitoring platform DownDetector also surged within a short period, indicating that the problem was not limited to individual accounts, a particular region’s network, or browser caches. As of IT Home’s publication time, the outage had not yet been resolved.

OpenAI has not yet disclosed a definitive root cause for the incident. Explanations such as a “server failure,” compute overload, infrastructure issues, or a model deployment incident remain possibilities rather than confirmed conclusions.

However, the simultaneous failure of ChatGPT and Codex deserves more attention from developers than a simple inability to open the chat interface. ChatGPT is a general-purpose AI gateway for individual users and teams, while Codex has already become deeply embedded in development workflows such as code generation, repository analysis, and task execution. Problems affecting both product lines suggest that the incident may involve more than a specific frontend page—it could affect authentication, sessions, task scheduling, model routing, or other shared infrastructure.

More Than Just “The Website Won’t Load”

For users who only occasionally use ChatGPT, an outage simply means asking their question later. But for teams that have integrated Codex into their daily development workflows, the impact directly affects engineering progress.

Typical scenarios include:

• Codex cannot continue repository-level code analysis, interrupting long-running tasks that have already started;
• Developers cannot obtain patches, testing recommendations, or error diagnosis results;
• Project context and conversation history in ChatGPT become temporarily inaccessible;
• Workflows that rely on the web interface for code review, document organization, and data analysis grind to a halt;
• Automated tasks continue retrying without proper timeout and circuit-breaker mechanisms, further exacerbating queue congestion and costs.

Coding agents are particularly affected. When an ordinary chat request fails, users can simply ask again. An agent task, however, may already have completed code searches, dependency analysis, and partial file modifications. If the service suddenly goes down at that point, the issue is not merely that “a piece of text was not generated.” The task is left in an intermediate state: which tools were called, which files were modified, and whether tests were actually run may all need to be verified again.

This is also the fundamental difference between agents and chatbots in terms of reliability requirements. Chat products are closer to providing one-off responses, whereas an agent effectively takes remote control of a workstation. If the latter disconnects, recovery must account for task state, consistency, and side effects, making the process far more difficult.

What DownDetector Can and Cannot Prove

DownDetector’s report curve can quickly indicate whether an issue is widespread, but it is not OpenAI’s internal monitoring system and cannot directly identify the root cause.

A sudden increase in reports usually indicates only that many users encountered problems at the same time. It cannot determine whether the failure occurred in:

1. The ChatGPT website or client;
2. Account login and authentication;
3. Conversation history and file storage;
4. Model inference clusters;
5. The Codex task orchestration system;
6. CDN, DNS, or upstream cloud infrastructure;
7. API gateways and regional routing.

Therefore, the last thing developers should do now is look at a single chart and conclude that “there is not enough model compute” or that “OpenAI is silently releasing a new model.” Large-scale AI services include multiple layers, such as gateways, authentication, queues, inference, caching, storage, and safety reviews. A failure in any shared component could present users with the same message: “Service unavailable.”

For example, if the authentication service fails, the model clusters may still be operating normally, yet users will remain unable to access ChatGPT. If the task queue fails, Codex may accept instructions but be unable to continue scheduling sandboxes and tools. If session storage latency rises, the interface may appear to have lost conversation history. The external symptoms may look similar, but the remedies are entirely different.

Until OpenAI publishes an official incident postmortem, it would be irresponsible to state any specific cause as fact.

API Impact Cannot Be Inferred Directly From a ChatGPT Outage

Current public information primarily concerns ChatGPT and Codex. Developers should pay particular attention to the fact that although ChatGPT, Codex, and the OpenAI API may share some underlying capabilities, they are not identical service entry points.

An outage affecting the ChatGPT website does not necessarily mean that the API is also unavailable. Conversely, the fact that the website loads does not guarantee that API latency, error rates, and streaming output are normal. To determine whether the API is affected, developers should consider the following signals:

• Whether OpenAI’s official status page separately identifies an issue with the API or a specific model;
• Whether application-side HTTP status codes suddenly cluster around 429, 500, 502, 503, or 504;
• Whether time to first token and total response time have suddenly increased;
• Whether streaming connections are frequently interrupted;
• Whether behavior is consistent across different models, regions, and accounts;
• Whether requests reach the server and whether failed requests incur charges.

If business monitoring records only that a “request failed” without retaining the status code, request ID, model name, retry count, and duration, then during an actual incident, the team will have almost no way to determine whether the problem lies with its own network, SDK, gateway, or the upstream model service.

The first practical lesson from this outage is that AI calls can no longer be monitored using only a single success-rate chart. The model output pipeline is longer than that of a traditional REST API, and long contexts, streaming, tool calls, and agent tasks can cause a single request to last tens of seconds or even several minutes. At a minimum, monitoring should separately track connection success rate, time to first token, midstream disconnection rate, tool-call failure rate, and end-to-end task completion rate.

Repeated Retries Are Not a Recovery Strategy

When a service experiences problems, the most common—and most dangerous—response is to let clients retry without limit.

If the upstream service is experiencing only a brief disruption, exponential backoff can help with recovery. But if the upstream service is suffering a systemic failure, large numbers of clients immediately retrying at the same time will create a “retry storm.” One failed request may be amplified into five or ten requests, making it even harder for gateways and queues to recover.

A reasonable strategy should include:

• Using exponential backoff with random jitter to prevent all instances from retrying simultaneously;
• Setting separate timeouts for individual requests and the entire business workflow;
• Handling 429 and 5xx responses differently rather than retrying all of them immediately;
• Setting a maximum retry count and total time budget;
• Adding idempotency safeguards for tool calls with side effects, such as writing files, sending messages, or committing code;
• Triggering a circuit breaker after consecutive failures reach a threshold, then quickly returning a degraded result;
• Retaining request IDs and task checkpoints so agent tasks are not blindly restarted from scratch after recovery.

Idempotency is especially important for coding agents. A “generate patch” operation can be rerun, but actions such as “push branch,” “create ticket,” and “publish release” must not be repeated after the network recovers. A model service outage is merely an upstream problem, but data corruption caused by duplicate submissions becomes the team’s own incident.

Multi-Model Backup Helps, but It Is Not as Simple as It Seems

Every time ChatGPT goes down, someone suggests immediately switching to Claude, Gemini, or another model. The general idea is sound, but simply “changing the model name” does not automatically provide genuine disaster recovery.

Different models vary in context windows, tool-calling protocols, structured-output reliability, execution of system prompts, and safety policies. This is especially true for coding agents: giving the same tool definitions to different models may result in entirely different call sequences and parameters. Switching directly when the primary model fails may not provide a degraded service—it may introduce a different category of unpredictable problems.

A truly usable multi-model disaster recovery strategy must address at least three issues.

1. Isolate Provider Differences Behind the Model Gateway

Business code should not hard-code provider-specific fields throughout the codebase. Only by standardizing interfaces, message formats, and error classifications can routing be adjusted quickly during an outage. OpenAI-compatible formats can reduce migration costs, but interface compatibility does not mean complete capability parity. Tool calls, reasoning parameters, and multimodal inputs still require separate validation.

2. Degrade by Task Instead of Switching Mechanically

Classification, summarization, and general question-answering tasks can be switched to a backup model. Complex code modifications, long-context analysis, and high-risk tool execution should instead be paused or handed over to a human. Not every request should be forced to completion during an outage.

A more practical tiering approach is:

• Low-risk tasks: Automatically switch to a backup model;
• Medium-risk tasks: Require structured validation or human confirmation after switching;
• High-risk tasks: Pause execution while preserving context and task checkpoints;
• Tasks with external side effects: Prohibit automatic continuation across models.

3. Conduct Failure Drills Regularly

If a backup model is enabled for the first time only when the primary service goes down, it is effectively no backup at all. Teams need to regularly replay real requests, compare output quality, latency, error rates, and tool-call success rates, and confirm that credentials, quotas, and routing rules are actually functional.

For teams using models such as GPT, Claude, Gemini, and DeepSeek, the value of aggregation gateways is shifting from “integrating fewer SDKs” to “unified observability and failover.” However, the gateway itself must also be highly available; otherwise, it merely replaces a provider’s single point of failure with the team’s own.

Reliability Is Now Part of Model Capability

Over the past two years, industry benchmarks have typically compared reasoning, coding, and multimodal capabilities while rarely including availability on the same leaderboard. For production environments, this evaluation approach is now outdated.

A model that scores a few percentage points higher on coding but frequently times out during peak hours may produce less real-world value than a slightly weaker but more stable model. Enterprises are not buying a benchmark score; they are buying a service that can complete tasks when needed. Success rates, tail latency, rate-limiting policies, fault isolation, and recovery speed should all be considered part of a model’s actual capabilities.

The simultaneous outage of ChatGPT and Codex also shows that AI companies are assuming responsibilities increasingly similar to those of cloud service providers. As users move chat, search, writing, coding, and even some automated operations onto AI platforms, the impact of an outage is no longer limited to casual question-answering. It can propagate through workflows into code repositories, document systems, and internal business operations.

OpenAI must answer more than just “When will service be restored?” It should also explain which products were affected, whether the API was impacted, how long the outage lasted, and how similar incidents will be prevented in the future. A simple statement that “the issue has been resolved” may be sufficient for ordinary users, but it is far from adequate for development teams that have incorporated Codex into production workflows.

What Development Teams Should Do Now

Before the official root cause and full scope of impact are disclosed, teams should perform the following checks:

• Pause high-risk Codex automation tasks and verify whether any operations were left partially completed;
• Inspect code repositories, ticketing systems, and deployment systems to rule out duplicate submissions or incomplete states;
• Review API monitoring rather than relying solely on the status of the ChatGPT website to determine API availability;
• Reduce retry frequency and enable exponential backoff, random jitter, and circuit breakers;
• Save critical prompts, context, and intermediate artifacts instead of keeping them only in online conversations;
• Enable validated backup models for low-risk tasks;
• Record the incident timeline and later review single points of dependency in internal workflows.

Our assessment is that this incident may not have a lasting impact on OpenAI, but it once again exposes an overlooked problem: AI has entered production environments, yet many teams’ reliability practices remain stuck at the stage of “refresh the page if the website won’t load.”

Models may occasionally give wrong answers, but critical workflows cannot be allowed to grind to a halt without preparation. For developers, the most important thing is not to speculate about whether this incident was caused by compute capacity, networking, or deployment. It is to ensure that the next time any model provider experiences an outage, their own systems do not go down with it.

References

• IT Home: OpenAI Suffers Sudden Server Failure, Taking ChatGPT and Codex Offline — Reports on the July 25 OpenAI service disruption, user feedback, and the increase in outage reports on DownDetector.