On Monday afternoon, August 31, ChatGPT Work had been failing for close to three hours. OpenAI's own incident text said users "may be unable to start or continue tasks." The status page banner said Partial System Outage, severity major.
OpenAI's status feed recorded that afternoon as follows, all times UTC. Every entry below is the vendor's own claim, with the time we read it.
What did the ChatGPT status page say, minute by minute?
OpenAI's banner and incident feed moved within minutes of each other, and the incident ran about five and a half hours. The entries below are the feed as published.
- 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.
- 20:28 - OpenAI marks the incident resolved: "All impacted services have now fully recovered."
The same afternoon, for the record, Anthropic's status page listed a claude.ai degradation from 17:23 to 17:52, impact minor. Twenty-nine minutes, opened and resolved promptly. Vendors vary, and the same vendor varies incident to incident.
Can a status page tell you whether ChatGPT is down?
A status page tells you only what the vendor claims. A user who searched "is ChatGPT down" and landed on a status page was reading the vendor's claim: a banner, an incident feed, and a component board. The status page vendor's API exposes these as separate objects, and a person has to keep them consistent while also fixing the incident. In this case, the banner and the incident feed moved within minutes of each other. Whether the component board agreed with them is a question a reader should check on the page itself, not assume.
We did not publish a probe reading of OpenAI's logged-in product that afternoon, and we could not have: 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. A probe reading of an API or a web edge is one measurement from one place at one time. It does not say whether the product people are using is working.
Why do status pages end up like this?
Status pages are graded by the vendor that runs them, so the failure is structural. 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 a product like "ChatGPT Work" may map to no component at all. The banner, the incident feed, and the checkmarks are separate systems that nobody is forced to reconcile. Add the quiet commercial pressure that a wall of green is a sales asset, and you can get days like this one: an honest banner floating above a board that says little.
What we do differently
We wrote up the design position in Status pages that can't lie.
- We keep the vendor's claim and our readings apart. 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 what we measured, in either direction.
- We publish each region's reading separately. A reading is one measurement from one place at one time, shown with its region, latency, timestamp and 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.
- We publish corrections. Our probes can be wrong, and when they are we retract what we published at /outages/corrections.
- Our own status page runs on the same machinery. The checkmarks on it come from the same checks that RealUptime Monitor runs, not from a human remembering to flip a toggle mid-incident.
The last point is the actual fix for the failure mode above, so it is worth spelling out.
An incident can have three unreconciled sources of truth: a banner someone updated, an incident feed someone wrote, and a component board nobody touched. Pairing RealUptime Monitor with RealUptime Status exists to prevent that. Monitor runs the checks; Status renders them.
A component on a Status page is a Monitor check, so its state is the measurement, updated as 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 measured, not remembering to update the state while everything is on fire.
The live view of OpenAI, with the vendor's claim beside each region's reading, is at realuptime.io/outages/openai.