Why does OpenAI's status page say everything is fine when Codex is down?

OpenAI publishes around 25 separate components covering the whole product range. A global indicator averages across all of them, so a Codex-specific failure can leave the overall indicator green. Status pages are also updated by humans after an incident is confirmed, which typically lags the first user reports by several minutes to half an hour.

Which components does Codex actually depend on?

Codex in ChatGPT Desktop, the Responses API surface that the CLI and editor extensions call, and Login. If any of those three is degraded, Codex is affected regardless of what the global indicator says.

OpenAI status vs Codex status: why they disagree

The official page is not lying to you. It is answering a different question.

It is a familiar moment: Codex is plainly broken, you open OpenAI's status page hoping for confirmation, and it is a wall of green. That mismatch has three separate causes, and knowing which one you are looking at tells you how long to wait.

Cause 1: the global indicator averages everything

OpenAI publishes roughly 25 components — images, audio, search, fine-tuning, batch, embeddings, moderation, Sora, and so on. The single indicator at the top of the page summarises all of them at once. A failure confined to the handful of components Codex actually uses barely moves that average, so the headline stays green while your CLI stays broken.

This is precisely why the live Codex status exists. Our verdict is scoped to the components Codex depends on rather than to the global roll-up:

Codex in ChatGPT Desktop — the only explicitly Codex-named component OpenAI publishes.
Responses — the API surface the Codex CLI and editor extensions actually call.
Login — no authentication, no Codex, no matter how healthy everything else is.

If any one of those is degraded, we say so, even when OpenAI's global indicator is green. Conversely, if Sora is having a terrible day and Codex is fine, we stay green while the official page may not.

Cause 2: status pages lag reality

Every status page in the industry works the same way: an incident is posted once a human has confirmed it. Between the first failing request and the first status update there is a gap, routinely ten to thirty minutes and occasionally much longer for partial degradations that are hard to distinguish from noise.

So “the status page says it is fine” is weak evidence in the first half hour of an incident and strong evidence after it. If you are five minutes into a problem, trust your own failing requests over the green tick.

Cause 3: it genuinely is not them

The uncomfortable third option. If the status feed is green, we are green, and your requests still fail, the cause is very likely local — an expired session, a rate limit, or a proxy. We have a page for each: CLI troubleshooting and rate limits.

Which should you trust?

For “can I work right now?” — a Codex-scoped check like this one, because it ignores the 22 components you do not use.
For “what actually broke, and is there an ETA?” — OpenAI's official page, because incident write-ups and resolution notes only exist there.
For “is this normal?” — our outage history, which counts how often this has happened before.

They are complements, not competitors. We read OpenAI's feed — we simply read a different slice of it than the front page does.

A note on what we are not

This is an independent, unaffiliated project. We do not have privileged information, we do not probe OpenAI's infrastructure, and we cannot tell you when an incident will be resolved. Everything here derives from the same public feed you can read yourself — the value we add is the scoping and the plain-English verdict, not inside knowledge.

Not affiliated with, endorsed by, or sponsored by OpenAI. OpenAI and Codex are trademarks of OpenAI. Status is read from the official status.openai.com feed.