GPT-6 Astra Pro threw elevated errors for 49 minutes on 24 September 2026. OpenAI identified the problem at 18:59 UTC and said it had applied a mitigation by 19:32 UTC. The fault sat with OpenAI's model serving, not with anything in your own stack.
Started
18:59 UTC
Duration
Lasted 49m
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.
What happened?
OpenAI logged one incident on this day, affecting GPT-6 Astra Pro. It started at 18:59 UTC, when OpenAI posted that users were experiencing elevated errors on that model and that a mitigation was being worked on. At 19:32 UTC OpenAI posted a second update saying the mitigation had been applied and that it was monitoring recovery. No further update was filed after that, and the incident's recorded duration is 49 minutes. OpenAI's status page lists no affected components for this incident, so there is no breakdown of which parts of the GPT-6 Astra Pro pipeline were hit beyond the error-rate description itself. No user reports were filed during the window on this page, so there is no first-hand account of what the errors looked like from outside OpenAI. The only record of what happened is OpenAI's own two updates, and that is the full extent of what can be said about this incident. Over the past 90 days OpenAI has logged 96 incidents with a median duration of 1 hour 52 minutes, so a 49 minute incident sits well under that median. Across all time OpenAI has recorded 950 incidents, averaging 15.1 a month. OpenAI has not published a post-mortem for this incident, and the cause is not on the record beyond "elevated errors" and "mitigation applied".
Learning
UptimeRobot's own 30 day figures for OpenAI show 40 incidents, 39 resolved, with a median duration of 1h 21m, which is a different slice of the same kind of failure: a model serving problem rather than a network or endpoint failure. This matters because a degradation inside a model's serving layer, like elevated error rates on one specific model, often will not show up as a dead endpoint. Your own health check against the API can stay green because the connection succeeds and the service responds, while a share of requests to that one model fail or degrade. That is the gap between watching your own integration and watching the provider's infrastructure: your check tells you your side is reachable, it does not tell you whether the model behind it is behaving. Pairing your own monitoring with a watch on the provider's status and incident history closes that gap. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
