What happened
OpenAI’s public status page recorded a degraded-performance incident titled “Elevated errors with search in Dots, ChatGPT Work, and certain ChatGPT thinking experiences.” The company said it was aware of issues affecting search in Dots and ChatGPT Work, as well as some ChatGPT thinking experiences. Its initial notice said OpenAI was investigating and would share updates on the status page.
The investigation update is timestamped 3:38 PM on Friday, October 30, 2026. OpenAI marked the incident resolved at 5:14 PM the same day. The published interval between those timestamps is about 96 minutes. The status page classifies the event as degraded performance rather than a full outage. It lists ChatGPT as the affected service family and identifies two affected components: ChatGPT Work and Dots.
The wording of the investigation notice is narrower than a general ChatGPT outage claim. It specifically refers to search in Dots and ChatGPT Work and to “some” ChatGPT thinking experiences. The source does not name individual models, regions, subscription plans, or customer accounts. Nor does it specify whether every search request in the listed components was affected or whether the problem appeared intermittently.
In the resolution notice, OpenAI said that all affected services were operating normally again, apologized for the disruption, and thanked users for their patience. The notice provides no technical root cause, mitigation description, error rate, request count, or user-impact estimate. No postmortem is linked from the incident record supplied here.
The page also includes a general reporting caveat: availability metrics are reported in aggregate across all tiers, models, and error types, while an individual customer’s availability may vary with subscription tier and the models and API features in use. Codex and the API do not appear in the affected-components list for this incident. That absence defines the published scope; it does not prove that no Codex or API customer encountered related symptoms.
What the archive adds
This is a new incident on a known reliability thread, rather than a restatement. A separate OpenAI degradation on October 20 affected APIs, ChatGPT, and Codex and was resolved in about an hour. This event instead names ChatGPT Work, Dots, and certain thinking experiences.
Trend signal
No supplied pattern directly addresses this narrowly described service incident.
Connections to other events
Recent archive coverage also includes a Claude disruption across Claude services and a Claude Sonnet 5.5 outage. These are separate events, not evidence of a shared cause, but together they show why teams should distinguish a provider incident from a defect in their own workflow.
Why it matters
For teams that use ChatGPT Work or search-dependent ChatGPT flows, a short provider incident can look like a failed internal deployment: a retrieval step may return errors, a thinking flow may not complete as expected, and users may receive inconsistent results. The practical issue is not simply uptime. It is whether a workflow has enough observability to identify the failing dependency and enough fallback design to keep a critical task moving.
The official scope matters here. The source names particular ChatGPT components and does not name the API or Codex. Teams should therefore avoid generalizing this event into a claim that every OpenAI surface was unavailable. At the same time, they should not treat an unlisted surface as definitively unaffected, because the page provides aggregate reporting and says customer experience can vary.
What happens next
- OpenAI will keep this incident in a resolved state without a public root-cause explanation. (3 months, 70%). Watch for: a subsequent update added to the incident page.
- Teams using ChatGPT Work search will add provider-status checks to incident triage where the workflow is business-critical. (6 months, 60%). Watch for: runbooks that distinguish search-provider failures from application defects.
Limits and uncertainty
The source establishes the incident title, affected components, timestamps, degraded-performance classification, and resolution statement. It does not establish why the errors occurred, how many requests or customers were affected, whether all regions or subscription tiers saw the issue, or what search operations failed. It also does not provide a service-level objective, error percentage, or a postmortem. The status page’s aggregate reporting note means the duration and scope should not be read as a measurement of every individual customer’s experience.
Skill to build now
This week, add a provider-status branch to the runbook for any critical workflow that relies on ChatGPT Work or a search step. Record the external dependency, the user-visible failure mode, a manual fallback, and the evidence needed to separate a provider outage from an application regression. During an incident, preserve timestamps and request context before changing prompts or redeploying. That reduces the risk of treating an external degradation as a self-inflicted bug and creating additional disruption while attempting a fix.
Reader takeaway
OpenAI resolved a roughly 96-minute degradation affecting Dots search, ChatGPT Work, and some ChatGPT thinking experiences on October 30. The published record is narrow and contains no cause, so use it as an operational signal: check dependency status, avoid overclaiming scope, and make critical search-dependent workflows recoverable.
Open question
Will OpenAI publish a root cause or more granular impact information for this incident, including whether particular tiers, regions, or thinking configurations were disproportionately affected?