OpenAI status page flags a wide outage across ChatGPT, Codex and the API

OpenAI reported degraded performance across ChatGPT, Codex and its APIs on October 21. The status page counts 33 affected components. A mitigation has been applied and OpenAI is monitoring recovery.

One incident, 33 components, three product families

The incident was opened as “Investigating” at 04:26 AM on the status page’s clock and moved to “Monitoring” a minute later, at 04:27 AM. The page was published at 02:27 UTC. For the second update, OpenAI wrote that it had “applied the mitigation and are monitoring the recovery.” The incident was not marked resolved at the time of writing.

The scope is unusually broad. On the API side, 14 components are flagged. They cover the core text endpoints (Chat Completions, Responses and Agents), plus Decisions, embeddings, image generation, audio, moderation and the Realtime interface. Fine-tuning, Batch, file handling, sign-in and Live are on the list too.

ChatGPT accounts for 16 more. Core pieces such as conversations, sign-in, search, file uploads and voice mode are affected, as are custom GPTs, image creation and Deep Research. So are the newer surfaces: ChatGPT Work, the Agent, dots, Space, Sites and connectors. The Compliance API and Codex inside the desktop app also appear. Codex itself has three entries: its web version, its API and the command-line tool.

OpenAI adds a caveat that applies to every incident on its page. Availability metrics are reported in aggregate across tiers, models and error types, so what an individual customer saw may differ by subscription tier, model and API feature.

What the status page does not tell developers

The entry is thin. It gives no cause, no error rates, no description of what users would have seen (slow responses, failed requests or login problems) and no estimate of when full recovery is expected. It does not say whether every listed component was actually failing or whether the list is a broad precaution. Teams running production workloads on the API cannot tell from the page alone whether retries, queued Batch jobs or interrupted fine-tuning runs need attention.

The shape of the list is itself informative. Sign-in appears under both the API and ChatGPT, which fits a shared dependency rather than separate product faults, though OpenAI has not said so. That is an inference from the component list, not something the company has stated.

The affected products also span newer and older features. We recently reported that OpenAI lets whole teams hand recurring work to ChatGPT through Space and dots, so scheduled and triggered tasks are one area where an outage would be felt without anyone at a keyboard. Whether any scheduled runs were missed is not established by the source.

The third incident in nine days for coding workloads

The October 21 notice follows two smaller entries on the same status page. On October 14, degraded performance in Codex and ChatGPT Work ran from 09:05 AM to 11:53 AM, about 2 hours 48 minutes, and the page described “elevated errors for the impacted services.” It did not state a cause.

On October 13, degraded performance with GPT-6.1 Sol in Codex and Work mode lasted from 10:18 AM to 6:36 PM, about 8 hours 18 minutes. A mitigation was applied at 11:30 AM, and the incident stayed open for roughly seven more hours. That page also gave no cause.

Those two were narrower, touching one or two ChatGPT components and the Codex surfaces. This one reaches the whole API, a different order of scope. The October 13 case also shows how long recovery can take after a mitigation is announced: more than six hours passed between “mitigation applied” and “resolved.” By that precedent, the “Monitoring” label on the current incident does not on its own say that users are back to normal.

The three entries do not prove a common cause, and none of the pages names one. What they show is a run of incidents touching Codex and Work mode within a nine-day window, while OpenAI is promoting Codex for work such as on-call triage. In an October 16 post, the company showed an engineer using a dot to investigate a 3am incident and start a Codex thread that he could steer from his phone.

What to check when OpenAI closes the incident

Three things would settle the open questions. First, the incident being marked “Resolved” with a final time, which gives the total duration to compare with the 2 hours 48 minutes and 8 hours 18 minutes of the earlier cases. Second, any published explanation of the cause, since neither of the two earlier October incidents provided one. Third, whether OpenAI’s aggregate availability figures show a visible dip for the API components.

Until then, developers with fallback providers or retry logic will want to watch their own error rates rather than rely on the status page. The page itself warns that its figures are aggregates, and for a mitigation applied within a minute of the first notice, it offers no data on how much traffic was affected.