ChatGPT and Claude failed yesterday. Their incidents did not overlap.
The new evidence confirms service problems on 29 September and recovery reports on 30 September. It does not establish a broad loss of model capability.
Timeline
| UTC | Provider and affected surface | Reported issue and recovery | Evidence boundary |
|---|---|---|---|
| 29 Sep, 14:00–14:59 Incident resolved 16:27 | Anthropic: Claude.ai, Claude Code, Cowork, and some Claude API requests | Anthropic’s status record says users saw elevated errors, login/session and task problems, and that some messages in the impact window may not have saved. It marks the incident resolved at 16:27 UTC. | Provider-reported service event. It does not measure completed-answer accuracy, model weights, account prevalence, or post-recovery quality. |
| 29 Sep, 17:52:52–23:14:02 | OpenAI: ChatGPT, Codex, and APIs including Agents API | OpenAI reported elevated errors, failed requests, login difficulty, and tasks that did not complete. It marked the incident resolved and said a detailed RCA would follow within five business days. | No RCA was published in the incident record at the latest check. The status page says availability metrics are aggregated and individual availability may vary by tier, model, and feature. |
| 30 Sep, opened 02:20:32 Latest update 10:34:34 | OpenAI: ChatGPT Space Pages | OpenAI reported errors creating or interacting with Pages, including tools and live sessions. At 10:34 UTC it said impacted services had recovered and monitoring continued. | Recovery update is a provider statement, not confirmation about every individual account. |
| 30 Sep, opened 05:47:57 Latest update 10:36:34 | OpenAI: ChatGPT Pro/Plus conversations | OpenAI reported elevated errors on Pro and Plus. At 10:36 UTC it said impacted services had recovered and monitoring continued. | This concerns paid-plan conversations and service access, not a controlled model comparison. |
What the sequence establishes
Both providers recorded problems on 29 September, but the stated Claude impact window ended at 14:59 UTC and OpenAI’s separate incident began at 17:52 UTC. The records therefore do not describe simultaneous failures. They provide no evidence of a shared dependency, though they also do not prove that no upstream dependency was shared.
The reported symptoms—failed requests, trouble signing in, unavailable sessions, and incomplete tasks—are availability and product-operation signals. A person who received no answer did not run a valid quality test. A completed answer that seems worse is a separate signal and needs its own task, model identity, settings, and baseline.
What to do after a failed request
- Check the provider’s status record for the exact timestamp, tier, feature, and surface.
- Save the request, error, response, task artifact, and visible model and plan details that are safe to share.
- After recovery, rerun the same task with the same prompt, context, route, tools, and settings. Compare only valid completed outputs against a saved baseline.
- If a task still fails, keep access, route, tool, and output-quality explanations separate before switching providers or model versions.
What would change this call
- OpenAI’s promised root-cause analysis or a provider timeline that identifies the error mechanism.
- Evidence that any account-specific failures continued after the provider declared recovery.
- Repeated, matched post-recovery tests showing lower performance on valid tasks, with model and surface identity recorded.
Sources
- Anthropic Status and incident history
- OpenAI, 29 September ChatGPT/Codex/API incident
- OpenAI, Space Pages incident and recovery updates
- OpenAI, Pro/Plus incident and recovery updates
Back to the current verdict · Read how we separate availability and capability