ChatGPT conversations and the Responses API threw elevated errors for 6h 35m on 22 October, starting at 02:18 UTC. OpenAI says the fault hit users in India, Japan and Korea, and it was on their side, not yours.
Started
02:18 UTC
Duration
Lasted 6h 35m
Source
IsDown
Next time
OpenAI is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: ChatGPT, APIs, Responses, Web
What happened?
OpenAI's own status page logged one incident on this day, titled "Elevated ChatGPT conversation and Responses API errors". It started at 02:18 UTC and ran for 6h 35m before being marked resolved. The components listed as affected were ChatGPT, APIs, Responses and Web, four in total, which points to a fault sitting somewhere common to both the chat interface and the API layer rather than one isolated product. OpenAI's first update at 02:18 said the issue was "impacting users in India, Japan, and Korea" and that they were investigating. A second update followed at 02:42, just 24 minutes later, saying a mitigation had been applied and they were monitoring recovery. After that, nothing further was filed. There is no third update confirming resolution in the record, only the stated 6h 35m duration for the incident. OpenAI's status page does not say what caused the errors, and no post-mortem has been published. No user reports were filed during the window on this page, so the only account of impact comes from OpenAI's own two updates. Over the preceding 90 days OpenAI logged 101 incidents with a median duration of 1 hour 39 minutes, so this incident ran longer than that median. Across all time OpenAI has filed 978 incidents, averaging 15.3 a month.
Learning
This incident sat in OpenAI's API and conversation layer, not in the kind of endpoint you'd typically ping from your own health checks, and it was geographically scoped to India, Japan and Korea rather than global, which is exactly the sort of fault that a simple uptime check on your own service can miss entirely. Your monitoring tells you whether your product responded to a request, but if the request chain depends on OpenAI's Responses API or ChatGPT backend and that backend is degraded only for certain regions, your dashboard can stay green while users in those regions still see errors. That is not a contradiction, both readings are correct for what each one measures. UptimeRobot's own 30 day figures for OpenAI show 42 incidents, all resolved, with a median duration of 1h 37m, which is in line with the 90 day median OpenAI itself reports, so this pattern of short, recurring, partially scoped errors is not unusual for this provider. If you build on OpenAI, it's worth watching their status page directly rather than assuming your own checks will catch a regional degradation. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
