OpenAI reported that it was investigating elevated errors affecting ChatGPT and Codex, according to an incident posted on its status page on September 3, 2026.
The incident was classified as degraded performance. At the time of the posted update, OpenAI said only that it was investigating the issue for the listed services; it did not identify a cause, specify which features were failing, provide a recovery estimate, or quantify the impact.
What changed
The immediate change is a reliability event spanning two prominent OpenAI products: ChatGPT, the company’s general-purpose AI interface, and Codex, its coding-oriented service. “Elevated errors” can mean users encounter failed requests or interrupted workflows, but the status update does not provide enough detail to determine the precise failure mode or whether it is limited to particular models, regions, account tiers, or product features.
OpenAI’s status page also notes that its availability figures are reported in aggregate across tiers, models and error types. That means a broad service designation should not be read as proof that every customer or workflow is equally affected. Individual experience may vary by subscription tier and the specific model or API capability in use.
Why operators should care
For teams that use ChatGPT for research, drafting, support operations or internal knowledge work, the short-term risk is straightforward: AI-assisted steps may take longer or fail unpredictably. The effect can be more consequential for engineering organizations that have put Codex into development loops, such as code generation, review assistance, debugging or task automation.
The incident is also a reminder that AI services should be treated like other external dependencies. A tool can be highly useful without being appropriate as a single point of failure. Organizations relying on AI in customer-facing or production workflows should be able to distinguish a model-service error from an application defect, upstream data issue or user-input problem.
Practical safeguards include:
- Showing clear retry and failure states rather than leaving users waiting indefinitely.
- Using bounded retries and backoff to avoid amplifying an upstream disruption.
- Preserving user inputs and in-progress work when a generation or coding task fails.
- Keeping manual procedures available for workflows with time-sensitive or customer-impacting outcomes.
- Monitoring provider status alongside internal error rates, latency and completion metrics.
For builders using APIs, incident handling should include idempotent job design where possible, queueing for non-urgent tasks, and explicit controls that can pause AI-dependent automations if failure rates climb.
What to watch next
The next meaningful signal will be an OpenAI update that identifies the affected components more precisely, explains the underlying cause, or marks the incident as resolved. Customers should check the status page and compare it with their own telemetry rather than infer the scale of impact from an aggregate incident label.
More broadly, the event highlights a maturity test for AI adoption. As generative tools move from optional productivity aids into software delivery and business operations, resilience is not just a provider concern. It is a product, engineering and continuity-planning responsibility for every company that builds on them.
