It is Monday afternoon, August 31. ChatGPT Work has been failing for close to three hours. OpenAI's own incident text says users "may be unable to start or continue tasks." The status page banner says Partial System Outage, severity major.
And every component on that same status page shows a green checkmark.
We are not guessing about any of this. We probe OpenAI continuously, we poll their status feed, and we keep the history. Here is the afternoon as our systems recorded it, all times UTC.
The timeline, as measured
- 14:29 - Our poller reads OpenAI's status page: "All Systems Operational," indicator none.
- 15:04 - OpenAI's incident begins (their own started_at timestamp): "ChatGPT Work seeing elevated errors and latency," impact major.
- 15:15 - Our feed poller picks the incident up, eleven minutes after it opened. Credit where due: the banner and incident feed were prompt.
- 15:24, 16:24, 17:24 - Every subsequent poll reads the same banner: Partial System Outage, major.
- 17:46 - We fetch their machine-readable component summary. Non-operational components: zero. Every checkmark green, two hours and forty-two minutes into a major incident.
- 17:52 - Latest incident update: still "identified," a mitigation still being implemented.
So the banner told the truth and the checkmarks did not. A user who searched "is ChatGPT down," landed on the component board, and scanned for red would have concluded everything was fine.
What our probes saw: it is not your region
The obvious question during any outage is "is it down for everyone or just me, and is it my region?" Here is the measured answer.
Between 15:00 UTC and publication we ran 765 checks against OpenAI's API, auth, and web surfaces from four regions (US-East, US-West, Europe, Asia-Pacific). Failures: zero. API latency averaged about 1.1 seconds against roughly 1.0 seconds in the same window yesterday, a difference too small to call an event.
We also ran an authenticated, real inference call, the kind a paying API customer makes: a completion request against a current model. It returned an actual completion in 0.54 seconds.
So: the OpenAI API is up, everywhere we can see. Auth is up. The chatgpt.com edge answers from every region we probe. What is broken is inside the ChatGPT product itself, and it is broken the same way from everywhere. There is no "bad region" to route around. If ChatGPT is failing for you, it is not your region, your ISP, or your VPN.
That distinction matters practically. If your product calls the OpenAI API, this incident is not your incident. If your team lives in ChatGPT, no amount of switching networks will help.
For honesty's sake, here is what we cannot see: ChatGPT's logged-in application surface sits behind a bot wall, like most consumer apps, so no external monitor can honestly claim to measure the in-app experience. Anyone who tells you otherwise is measuring a login page. We say "the product plane, as described by the vendor's own incident text" because that is exactly as far as the evidence goes.
Why status pages end up like this
We do not think anyone at OpenAI sat down and decided to deceive. The problem is structural, and it is the reason this company exists.
A vendor status page is graded by the vendor. Component states are flipped by hand, usually by an engineer who is busy fixing the actual outage. The component list itself is chosen by the vendor, at the granularity the vendor prefers, and "ChatGPT Work" apparently maps to no component at all. The banner, the incident feed, and the checkmarks are three separate systems that nobody is forced to reconcile. Add the quiet commercial pressure that a wall of green is a sales asset, and you reliably get days like today: an honest banner floating above checkmarks that say nothing is wrong.
The same afternoon, for the record, Anthropic ran a claude.ai degradation from 17:23 to 17:52. Twenty-nine minutes, opened and resolved promptly. Vendors vary, and the same vendor varies incident to incident. That variance is exactly why you should not have to depend on any of them.
What we do differently
We wrote up the design position in Status pages that can't lie; today is what it looks like in practice.
- Verdicts come only from measurement. Our verdict for OpenAI today stayed "up" because everything we probe is up. Their incident appears on our OpenAI page as what it is: their claim, quoted, timestamped, attributed. We never merge a vendor's self-assessment into our verdict, in either direction.
- We probe the thing, not the brochure. Deep endpoints, auth planes, and authenticated real-transaction probes, not marketing homepages that a CDN will happily serve during a total backend failure.
- Every reading says where and when it came from. Region, latency, timestamp, freshness. A stale reading declares itself stale instead of impersonating a fresh one.
- "Blocked" is not "down." When a bot wall stops us from measuring, we say we could not measure. We publish our methodology and probe IPs, and any operator can opt out.
- Our own status page runs on the same machinery. The checkmarks on it come from the same probes you are reading here, not from a human remembering to flip a toggle mid-incident. The tempting lie is structurally unavailable to us too.
And that last point is the actual fix for today's failure mode, so it is worth spelling out. Today's incident had three unreconciled sources of truth: a banner someone updated, an incident feed someone wrote, and a component board nobody touched. This is what pairing RealUptime Monitor with RealUptime Status exists to prevent. Monitor runs the checks; Status renders them. A component on a Status page is a Monitor check, so its state is the measurement, updated the moment the checks fail, from the same data, whether or not anyone is free to update a page. Mid-incident, the people who know the truth are always busy with the incident. With Monitor feeding Status, the human's job becomes adding words to a state that is already honest, not remembering to make the state honest while everything is on fire. If today's page had been driven that way, the board and the banner could not have spent three hours contradicting each other.
The incident is still open as of publication. The live, measured view is at realuptime.io/outages/openai, and it will keep updating whether or not anyone flips a checkmark.