status.openai.com

OpenAI Status can report "We're fully operational" while you still hit errors because the page measures availability at an aggregate level across all tiers, models, and error types. The page itself notes that individual customer availability may vary depending on subscription tier and the specific model and API features in use. So a green page means no broad, platform-wide incident is detected — not that your particular request path is healthy.

What the status page actually measures

The uptime figures on status.openai.com are rolled up per component group. For example, the APIs group lists 14 components with 99.97% uptime over Jul 2026 – Oct 2026, and ChatGPT lists 16 components at 99.70%. Those numbers combine all tiers, all models, and all error types into one figure.

Two consequences follow:

• A single degraded model or feature can be diluted by healthy traffic on everything else in the same group.
• A problem isolated to your tier, region, or request pattern may never move the aggregate number enough to trigger an incident.

The page states this directly: "Availability metrics are reported at an aggregate level across all tiers, models and error types. Individual customer availability may vary depending on their subscription tier as well as the specific model and API features in use."

Check the component that matches your workload

The page breaks status down by product area, so start there rather than at the top-line banner. Relevant groupings include:

If your failures cluster on one component — say Realtime or Codex CLI — compare that component's figure and history rather than the overall banner. A component at 100% still only means no detected aggregate issue for that component.

Use history and subscriptions to confirm timing

Two features help you distinguish "known incident I missed" from "something specific to me":

1. View history — check whether an incident overlapped your error window, even if the current banner is green. Incidents are often resolved before you look.
2. Subscribe to updates — the page offers a subscription option so you receive incident notifications as they are posted, instead of discovering them after the fact.

If history shows no incident during your failures, the cause is more likely local: your API key or tier limits, a specific model or feature combination, request format, network path, or client-side configuration.

A practical triage order

1. Confirm the current banner and the specific component you depend on.
2. Open View history and check the exact window of your errors.
3. Subscribe to updates so future incidents reach you directly.
4. If no incident matches, treat it as a client-side or account-specific issue: verify the model and feature you are calling, your tier's access, and your request/response handling.
5. When contacting support, include the component name, timestamps, and error types — the aggregate metrics won't show your individual pattern, so your own evidence is what makes the case diagnosable.

The short version: a clean status page rules out a broad outage, not your specific failure. Match the component, check the history window, and then look at your own tier and request path.

OpenAI Status (status.openai.com) tracks availability across five service groups: APIs (14 components), ChatGPT (16 components), Codex (4 components), FedRAMP (1 component), and Ads Platform (2 components). If your product or feature appears in one of these groups, its uptime and incident history are reported there. The page currently shows "We're fully operational," with no known issues affecting systems.

APIs (14 components)

The API group covers the developer-facing endpoints:

Group aggregate: 99.97% uptime.

ChatGPT (16 components)

The ChatGPT group covers the consumer and workspace surfaces:

Group aggregate: 99.70% uptime.

Codex (4 components)

Group aggregate: 99.94% uptime. Note that Codex also appears inside the ChatGPT group as "Codex in ChatGPT Desktop," tracked separately from the standalone Codex components.

FedRAMP (1 component)

A single FedRAMP component, showing 100% uptime for the period.

Ads Platform (2 components)

What the figures do and don't tell you

The page states that availability metrics are reported at an aggregate level across all tiers, models and error types, and that individual customer availability may vary depending on subscription tier and the specific model and API features in use. So a 100% figure for a component does not guarantee your particular tier or model saw zero errors.

To check whether your product is covered, match it to a component name above. If it isn't listed—for example, a feature you use that has no corresponding component—the status page won't reflect its availability. You can subscribe to updates from the page to be notified of incidents.

Go to status.openai.com and use Subscribe to updates to receive incident notifications, then check the current status banner and the affected component list to see whether an issue touches the product you use. For past incidents and uptime trends, open View history. The page reports availability in aggregate across all tiers, models, and error types, so your own experience can differ depending on your subscription tier and the specific features you use.

Check the current status first

The page opens with a plain-language banner. When everything is healthy it reads "We're fully operational" with a note that no issues affecting the systems are known. When something is wrong, this banner is where the incident summary appears.

Below the banner, the System status section lists each product area with its component count and uptime percentage. The page groups components under these headings:

Within each group, individual components carry their own figures. For example, under APIs, Chat Completions, Responses, Agents, Decisions, Fine-tuning, Embeddings, Batch, Audio, Moderations, Realtime, and Files each show 100% in the sample, while Images shows 99.990% and Login 99.98%. Under ChatGPT, Conversations is 99.95%, Login 99.93%, ChatGPT Work 99.90%, and Codex in ChatGPT Desktop 99.91%, with several components at 99.998%.

How to use this: find the component that matches what you are doing — Chat Completions for API calls, Conversations for chat sessions, Codex Web or CLI for coding tools, Login if you cannot sign in — and read its status and uptime rather than relying only on the top-level banner.

Subscribe to updates

The Subscribe to updates option on the page is the intended way to be notified about incidents rather than refreshing manually. Use it if you want incident and recovery notices pushed to you; the page presents it as the subscription entry point for status updates.

A practical routine:

1. Open status.openai.com when a request fails or a feature misbehaves.
2. Read the banner for an active incident summary.
3. Locate your specific component in the System status list.
4. Subscribe to updates so future incidents reach you without a manual check.
5. If the banner says operational but you still see errors, treat it as a possible account-, tier-, or feature-specific problem rather than a platform-wide outage.

Review history for past incidents and uptime

View history opens the record of past incidents and the uptime figures behind the percentages. Use it to answer questions like "was this outage already reported?" or "has this component been flaky this month?" The sample period on the page runs Jul 2026 – Oct 2026, and the uptime numbers shown are calculated over that window.

Uptime percentages are a quick signal, not a guarantee. A component at 99.998% can still have had a brief blip; a component at 99.70% (the ChatGPT group figure) has had more accumulated downtime than the API group at 99.97%.

Why your experience may not match the page

The page states that availability metrics are reported at an aggregate level across all tiers, models, and error types, and that individual customer availability may vary depending on subscription tier and the specific model and API features in use. Two consequences:

• A component can show high uptime while a particular model or feature you rely on had a rough patch.
• An incident affecting one tier may not appear as a broad outage.

So use the page to confirm whether a known incident exists, and use the component-level figures to narrow down where the problem sits. If both look clean and your errors persist, the issue is likely specific to your account, key, or configuration rather than the platform status.

status.openai.com is OpenAI's official service status page. It tells you whether OpenAI systems are currently operating normally, whether any known issues are affecting them, and how much uptime each product area has had over the recent reporting window. Use it when you want a quick, authoritative check on whether a problem you're seeing is on OpenAI's side rather than your own.

What the page shows

Current operational state

At the top, the page displays a plain-language summary of overall health. When everything is working, it reads "We're fully operational" with the note that OpenAI is "not aware of any issues affecting our systems." If an incident is active, this area is where the affected systems and their status would be surfaced.

Component-level status and uptime

Below the summary, the page breaks OpenAI products into groups of components, each with its own uptime figure. The reporting window shown is Jul 2026 – Oct 2026, and metrics are aggregated across all tiers, models, and error types.

Individual components within those groups include:

• APIs: Chat Completions, Responses, Agents, Decisions, Fine-tuning, Embeddings, Images (99.990%), Batch, Audio, Moderations, Realtime, Files, Login (99.98%), Live — most at 100%.
• ChatGPT: Conversations (99.95%), Login (99.93%), ChatGPT Work (99.90%), Codex in ChatGPT Desktop (99.91%), Compliance API, Search, File uploads, Voice mode, GPTs, Image Generation, Deep Research, Agent, dots, Space, Sites, Connectors/Apps — several at 99.998%.
• Codex: Codex Web, Codex API, CLI, and VS Code extension, all at 99.94%.

Subscriptions and history

The page offers a "Subscribe to updates" option so you can be notified when status changes, and a "View history" link to review past incidents and uptime over time.

How to use it

1. Check the summary first. If it says fully operational, the disruption you're experiencing is likely local (network, credentials, client configuration) or limited to a specific model or feature.
2. Drill into the relevant component. Find your product group and the specific component — for example, Chat Completions under APIs or Codex Web under Codex — and compare its uptime with the group average.
3. Read the caveat. OpenAI notes that "individual customer availability may vary depending on their subscription tier as well as the specific model and API features in use." A high aggregate uptime does not guarantee your particular tier or feature was unaffected.
4. Subscribe or check history if you need a record of past incidents or want proactive alerts.

What it does not tell you

The page reports aggregate availability, not per-account diagnostics. It won't explain why your specific request failed, and a 100% component figure doesn't rule out an issue scoped to one model, tier, or region. For those cases, combine the status page with your own logs and error messages.

The OpenAI Status page (status.openai.com) answers two different questions, and reading it correctly means keeping them separate. The top banner tells you whether OpenAI currently knows about any problems ("We're fully operational" means no known issues affecting its systems). The uptime percentages below tell you how reliable each component has been over a selected date range. A component can show 100% uptime for the period and still be down right now, or show a dip from last month while working normally today. Check the banner first for "is it down right now," then the component list for "how reliable has this been."

What the overall status message means

The banner is a statement about known issues, not a guarantee. "We're fully operational" is paired with the wording "We're not aware of any issues affecting our systems" — so if you're seeing failures while the banner is green, the page simply hasn't registered the problem yet. In that case, the useful next steps are the component list (to see whether your specific product is flagged) and the history view, rather than assuming the page is wrong.

When an incident is active, the banner changes and the affected components are marked, so the banner and the component list should be read together.

The component groups

Components are organized into product families, each with its own component count and aggregate uptime:

Two practical points follow from this structure:

• Find your actual dependency, not the brand name. If you build on the API, "ChatGPT 99.70%" is not your number — look at the specific API component you call, such as Chat Completions or Embeddings. Likewise, a Codex CLI user should watch the CLI component rather than the Codex group average.
• Group figures are aggregates. The group-level percentage rolls up its components, so a single weak component can pull the group number down while everything you use is fine.

Reading the uptime percentages

Each component shows a percentage over the displayed range (the page shows a Jul 2026 – Oct 2026 window in the captured data). The figures are reported at an aggregate level across all tiers, models, and error types.

That last sentence is the most important caveat on the page, and the page states it directly: individual customer availability may vary depending on subscription tier and the specific model and API features in use. So a 99.97% API figure is a population-level statistic, not a promise about your account. Treat small differences between components — say 99.998% versus 99.99% — as noise rather than a meaningful reliability ranking, and treat the percentages as a way to spot which areas have had incidents, not to predict your own experience.

A rough way to translate the numbers: 99.99% over a month is a few minutes of disruption; 99.9% is closer to tens of minutes; 99.7% (the ChatGPT group figure in the sample) is on the order of a couple of hours. Use this only to gauge scale — the page does not break downtime into incident durations per component.

A worked example

Suppose your application calls the Embeddings API and your users report failures.

1. Check the banner. If it says fully operational, no incident is acknowledged yet.
2. Check the Embeddings component specifically. If it shows 100% for the period, the historical figure won't explain today's failure — the issue may be new, or on your side (credentials, rate limits, network).
3. Check adjacent components you depend on: Login (99.98% in the sample) if your failures are authentication-related, or Files if you upload before embedding.
4. Open the history view to see whether similar components had recent incidents that match your symptoms.

This sequence avoids the common mistake of reading a high uptime percentage as "everything is fine right now" or a group-level dip as "my specific endpoint is broken."

Common pitfalls

• Confusing "no known issues" with "no issues." The banner reflects OpenAI's awareness, which lags real-world failures.
• Using group uptime as your SLA input. The page explicitly says availability varies by tier, model, and feature; the aggregate is not a contractual figure for your use.
• Ignoring the date range. Percentages are computed over the selected window. A 100% reading for a quiet period says nothing about a busy one.
• Over-reading tiny gaps. Differences at the third decimal place are not a reliable signal of which component to trust more.

If you need to track changes over time, the page offers a subscribe-to-updates option and a history view; those are the right tools for following incidents rather than re-checking the same percentages.