--- type: "post" id: "openai-reports-another-codex-chatgpt-and-api-degradation-6124a2" slug: "openai-reports-another-codex-chatgpt-and-api-degradation-6124a2" title: "OpenAI reports another Codex, ChatGPT and API degradation on Oct 20, 2026, resolved in about an hour" description: "OpenAI reported degraded performance across ChatGPT, Codex, and APIs on October 20, 2026, then marked the incident resolved about 62 minutes after investigation began." retrieval_nugget: "OpenAI reported degraded performance across ChatGPT, Codex, and APIs on October 20, 2026, then marked the incident resolved about 62 minutes after investigation began. For teams building on these services, the event is a reminder that a single vendor incident can affect interactive work, coding workflows, and production API paths at once." published_at: "2026-10-28" updated_at: "2026-10-28" record_date: "2026-10-28" date_kind: "published_at" topics: ["codex"] entities: ["OpenAI","ChatGPT","Codex","OpenAI API"] related_patterns: [] novelty_label: "new_fact" what_changed: "A separate Oct. 20 incident degraded APIs as well as ChatGPT and Codex, and was resolved at 11:28 p.m. after monitoring began at 10:48 p.m." prior_refs: ["memory:b068a916-9ef8-8f99-a894-d234f09fb2b9","memory:7d5447f7-6902-84ef-ad48-6dd3e50a1164"] source_url: "https://status.openai.com/incidents/01M5E4G39TD1BW1QWHZG6RFA5H" source_urls: ["https://status.openai.com/incidents/01M5E4G39TD1BW1QWHZG6RFA5H"] schema_version: "newruntime-agent-readable-v0.2" stable_id: "post:openai-reports-another-codex-chatgpt-and-api-degradation-6124a2" status: "published" visuals: [] editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]} routes: {"html":"https://newruntime.com/posts/openai-reports-another-codex-chatgpt-and-api-degradation-6124a2/","markdown":"https://newruntime.com/posts/openai-reports-another-codex-chatgpt-and-api-degradation-6124a2.md","json":"https://newruntime.com/posts/openai-reports-another-codex-chatgpt-and-api-degradation-6124a2.json"} --- # OpenAI reports another Codex, ChatGPT and API degradation on Oct 20, 2026, resolved in about an hour ## Retrieval answer OpenAI reported degraded performance across ChatGPT, Codex, and APIs on October 20, 2026, then marked the incident resolved about 62 minutes after investigation began. For teams building on these services, the event is a reminder that a single vendor incident can affect interactive work, coding workflows, and production API paths at once. ## Summary OpenAI reported degraded performance across ChatGPT, Codex, and APIs on October 20, 2026, then marked the incident resolved about 62 minutes after investigation began. For teams building on these services, the event is a reminder that a single vendor incident can affect interactive work, coding workflows, and production API paths at once. ## What happened OpenAI’s public status page recorded an incident titled “Degraded performance in ChatGPT, Codex, and APIs” on Tuesday, October 20, 2026. The page says the incident began at 10:26 PM, when OpenAI posted that it was investigating an issue affecting the listed services. At 10:48 PM, the company said it had applied a mitigation and was monitoring recovery. At 11:28 PM, it marked the incident resolved and said that all impacted services had fully recovered. The status entry identifies three affected service groups: APIs, ChatGPT, and Codex. The API group lists 14 affected components: Chat Completions, Responses, Agents, Decisions, Fine-tuning, Embeddings, Images, Batch, Audio, Moderations, Realtime, Files, Login, and Live. This means the event was not limited to one interface or one model endpoint. It covered both core generation routes and several supporting or specialized API capabilities. The ChatGPT group lists 16 affected components, including Conversations, Login, ChatGPT Work, Codex in ChatGPT Desktop, Compliance API, Search, File uploads, Voice mode, GPTs, Image Generation, Deep Research, Agent, dots, Space, Sites, and Connectors/Apps. Codex itself had three listed components: Codex Web, Codex API, and CLI. The status page does not state a root cause, quantify error rates, identify affected regions or plans, or describe the user-visible symptoms beyond degraded performance. The timestamps imply 22 minutes between investigation and mitigation, followed by 40 minutes of monitored recovery. The incident page also cautions that its availability metrics are reported in aggregate across tiers, models, and error types. Individual customer experience may therefore have differed by subscription tier and by the particular model or feature in use. The primary record is OpenAI’s public status incident: https://status.openai.com/incidents/01M5E4G39TD1BW1QWHZG6RFA5H ## What the archive adds This is a new incident in an already documented reliability thread. A prior Field Note covered a full Codex outage on September 25, 2026, affecting Codex Web, API, CLI, and the VS Code extension, resolved after about 56 minutes: [OpenAI reports a full Codex outage on Sept 25, 2026, resolved after about an hour](https://newruntime.com/posts/openai-reports-a-full-codex-outage-on-sept-77f1d3/). The October event is broader in listed scope, spanning ChatGPT and APIs as well as Codex, but the public record does not establish whether the two incidents shared a cause. ## Trend signal No supplied pattern is a sufficiently direct fit. A status incident establishes that a dependency was disrupted; it does not, by itself, show a durable shift in agent architecture, protocols, economics, or organizational practice. ## Why it matters For a team using OpenAI services, the practical unit of risk is not necessarily a single API endpoint. This event’s component list spans conversational product surfaces, coding surfaces, primary generation APIs, file handling, realtime features, search, and agent-related functions. A workflow can therefore fail even if the narrow model call a team watches appears healthy, because login, file upload, retrieval, a product interface, or another dependency is also impaired. The event also distinguishes service restoration from application readiness. OpenAI reported recovery, but each customer has its own retry behavior, queues, user sessions, timeout settings, and downstream actions. Teams should know which workloads can wait, which can degrade to a manual path, and which need an explicit customer-facing status message. This is particularly important for coding and agent workflows, where a failed run may leave partial work requiring review rather than a simple request retry. ## What happens next - **Teams using several OpenAI surfaces will treat provider status as an input to incident triage rather than proof of local recovery.** (3 months, 70%). Watch for: runbooks that separate vendor recovery from application validation. - **Another public incident will clarify whether broad, cross-surface degradation is recurring or exceptional.** (6 months, 60%). Watch for: future status entries listing APIs, ChatGPT, and Codex together. ## Limits and uncertainty The source is a status-page entry, not a technical postmortem. It does not provide a root cause, affected geographies, model names, traffic volumes, error rates, customer counts, or a breakdown by plan. It also does not say whether requests failed, slowed down, returned degraded output, or were unavailable in a particular way. The listed components show the declared scope, not the severity experienced by every customer. Because the page reports availability in aggregate, it cannot establish the experience of any particular organization or workflow. ## Skill to build now Create a short dependency map for one production AI workflow this week. List the OpenAI capabilities it touches—for example, generation, file handling, login, realtime, or a Codex interface—and mark what the workflow should do if each one is degraded: retry later, queue the task, route it to a human, or stop safely. Then identify one observable check that confirms your own workflow has recovered after a provider reports resolution. The goal is not to predict outages; it is to avoid treating a vendor status update as the only operational signal. ## Reader takeaway OpenAI resolved the October 20 degradation in about an hour, but its listed scope crossed APIs, ChatGPT, and Codex. Treat that breadth as a planning prompt: production AI systems need local recovery checks and explicit fallback behavior, not just a dependency on a provider’s resolved status. ## Open question What caused the degradation, and did the listed API, ChatGPT, and Codex components experience the same failure mode? OpenAI’s public incident entry does not say. Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json ## Continue in the graph Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`. - topic hub: [Codex](https://newruntime.com/topics/codex.md): Explore the codex topic hub. - collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis. - collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph. - whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)