Late at night on May 27, OpenAI confirmed that ChatGPT and the API were experiencing high latency, which was resolved after about five hours. This marks the second significant stability incident in a short period, reigniting developers’ concerns over reliance on a single point of failure.

OpenAI Crashed Again: Review of ChatGPT and API High Latency Incident

If you were calling OpenAI’s API to write code or run batch tasks last night (May 27), you probably felt a familiar lag — requests sent out, no response for ages, and occasionally a timeout. It’s not your network; OpenAI itself ran into trouble again.

At 22:47 Beijing time on May 27, OpenAI officially confirmed on its status page that ChatGPT and the API were experiencing "elevated latency," and also posted on X. The entire incident lasted for more than 5 hours, until 04:06 Beijing time today (May 28), when the company announced that it had been resolved.

This in itself isn’t exactly major news — large language model services hiccuping is nothing new. But in the context of the past month or two, the situation feels a bit different.

OpenAI status page showing timeline of elevated latency incident for ChatGPT and API

Incident Process: A Typical “High Load” Wobble

According to user feedback from X, Reddit, and domestic communities, early signs of the issue appeared from midnight Beijing time on May 27 — ChatGPT’s web interface became noticeably slow, taking 10–20 seconds of spinning before starting to generate a reply for a normal question. API behavior was even more obvious: p95 latency spiked, and some long-context requests returned 504.

OpenAI’s official timeline was roughly as follows:

From early morning: Users gradually reported abnormal latency, but no official alert was triggered
22:47: Status page posted “Elevated latency on ChatGPT and API”
04:06 the next day: Marked as resolved

Notably, there was nearly a full day between user perception and official acknowledgment. This isn’t the first time OpenAI has been criticized for slow incident response — its status page has traditionally been conservative, often waiting until internal error rate thresholds are crossed before admitting issues publicly.

This time, the official postmortem wasn’t published; the cause was vaguely categorized as "high latency." But from the nature of the failure, it’s almost certainly related to capacity scheduling — either an inference cluster in a certain region was overloaded, or a traffic spike hit during a rollout of a new version without proper throttling.

Unresolved Leftovers: Codex and Enterprise Edition Still Have Issues

Although the main incident was marked as resolved, there were still two small red dots on the status page:

Codex context compression slower than expected — directly impacts long-document programming tasks, especially when using Codex to handle large codebases; slower compression means initial token delay (TTFT) for each interaction is longer.
Android ChatGPT Enterprise workspace switching anomaly — a client-side issue, affecting fewer users, but annoying in multi-account scenarios for enterprise customers.

These two problems have been unresolved for several days, indicating that OpenAI has some deeper engineering debt. Codex’s slow context compression is essentially a model optimization problem, possibly involving KV cache management or speculative decoding path tuning — not something a simple service restart can fix.

Why Has OpenAI Been Dropping the Ball Lately?

Zooming out on the timeline makes the picture clearer. Here are some notable incidents from this year:

May 27: This high latency incident, lasted over 5 hours
Early November previously: ChatGPT and API error rates surged, services interrupted for over 1 hour, marked by OpenAI as a “Major Outage”
Earlier still: Multiple instances of GPT-4 series models experiencing heavier throttling during North America morning peak hours

Several structural reasons are hard to ignore here.

First, user growth is still outpacing capacity expansion. ChatGPT’s weekly active users long surpassed 1 billion, and recently, with GPT-5 series and the new Sora released, per-user token consumption is growing exponentially — especially requests involving visual comprehension, long context, and reasoning mode, which consume far more GPU compute than traditional chat.

Second, model routing and hybrid deployment are increasingly complex. OpenAI now maintains GPT-5, GPT-5-mini, the “o” series reasoning models, and Codex specialty models across multiple product lines, each with different hardware mix and scheduling strategies. Any capacity adjustment on one line can ripple across — e.g., prioritizing inference compute for the “o” series may cause GPT-5 mainline to wobble during peak hours.

Third, global traffic imbalance. North American weekday mornings (corresponding to Beijing night to morning) have traditionally been high-risk periods for OpenAI incidents. This incident also began Beijing time early morning, fitting that pattern exactly.

How Should Developers Respond?

If you integrate OpenAI’s API into production systems, this incident reminds us again: no single vendor can be trusted 100%. Here are some practical engineering suggestions.

1. Streaming Output Is the Baseline, Not an Optimization

An old but important point: If you’re still calling the API in synchronous blocking mode, during high latency incidents you’ll see mass timeouts. stream=true at least lets users see the response start within seconds, making it far more acceptable psychologically:

response = client.chat.completions.create(
    model="gpt-5",
    messages=[{"role": "user", "content": prompt}],
    stream=True,
)
for chunk in response:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

With SSE pushed to the frontend, the improvement is immediate.

2. Configure Reasonable Timeout and Retry Policies

A common mistake is relying on SDK defaults — default timeouts are often 600 seconds (10 minutes). During high latency incidents, connections hang and quickly pile up zombie requests. It’s better to explicitly set:

Short tasks (normal Q&A): timeout 30–60 seconds
Long tasks (code generation, long documents): 60–180 seconds
Retries with exponential backoff, but limit total attempts (2–3 times is enough)
Retry only for idempotent requests; be careful with non-idempotent ones (e.g., with side effects via Function Call)

3. Multi-Model Fallback Is Not a Luxury

This outage lasted 5 hours. If your service could automatically switch to Claude or Gemini in that period, continuity would be a completely different story. Technically, it’s not hard — all major model APIs now conform to the OpenAI-compatible format, so switching is essentially changing base_url and model name.

Incidentally, this is why API aggregation gateways are becoming popular. Platforms like OpenAI Hub (openai-hub.com) connect GPT, Claude, Gemini, DeepSeek, and other mainstream models through a single key, compatible with OpenAI format and directly reachable from China — in the event of an OpenAI hiccup, business-side can switch seamlessly without applying for keys and maintaining separate SDKs for each.

4. Cache and Degrade Strategies Must Be Designed Upfront

Semantic cache for popular prompts, rules for degraded operation (returning template responses or routing to human support) — these shouldn’t be cobbled together when an incident hits, but considered at the architecture stage.

Conclusion: Stability Is Becoming a Competitive Moat

Two years ago, competition was about model capabilities — whoever topped the benchmarks would win. Now GPT-5, Claude, and Gemini each lead in different rankings, and capability gaps are less pronounced. As model capabilities reach parity, SLA, stability, latency, and pricing — these engineering metrics are becoming key variables for B2B decisions.

For personal users, a 5-hour high latency incident is just something to complain about. But for companies whose core business flows through the API, it could mean real financial loss. Each such incident pushes a wave of users toward multi-vendor fallback architectures — a trend that’s been ongoing for over a year, and accelerates with every outage.

OpenAI certainly knows where the problems lie. Sam Altman has repeatedly said in recent interviews that "compute is the bottleneck." But capacity expansion is a slow variable; the next batch of data centers won’t come online until later this year. Until then, similar latency incidents will likely happen again.

Be mentally prepared, and be technically prepared.