The Routing Change That Took ChatGPT Down
The Routing Change That Took ChatGPT Down
3:00 AM.
The dashboards started turning red.
ChatGPT requests were failing. Codex was throwing errors. Users weren't seeing a clean “service unavailable” message either. Some requests worked, others didn't.
That is the nightmare scenario.
Not completely down.
Intermittently broken.
On September 3, OpenAI reported elevated errors across ChatGPT and Codex. The incident was eventually resolved, but reporting around the event pointed to a routing error as the trigger.
And this is where the incident becomes interesting for a DevOps engineer.
Because routing is supposed to be invisible.
Until it isn't.
A bad routing decision can send traffic toward the wrong destination, an unhealthy path, or a capacity boundary that wasn't expecting the load. Suddenly, an application that looks perfectly healthy at the container level can still be unreachable from the user's perspective.
The instinctive reaction during an outage is usually:
“Restart the pods.”
But what if the pods aren't the problem?
That's the lesson.
Production troubleshooting isn't about guessing which component is broken. It's about following the request.
User → DNS → network → load balancer → routing → service → application → dependency.
Find where the request stops.
And don't stop troubleshooting just because one dashboard turns green.
The September 3 incident was followed by another APAC degradation on September 4, affecting ChatGPT, Work, image generation, file uploads, Voice and Codex Cloud. Then, on September 8, file uploads experienced delays and failures before OpenAI reported full recovery.
Different symptoms.
Different failure domains.
Same uncomfortable reality:
Modern platforms rarely fail at one layer.
For DevOps engineers, the real skill isn't memorizing Kubernetes commands.
It's learning how to enter the war room, build a hypothesis, trace the dependency chain, validate it with metrics and logs, and recover without making the blast radius worse.
That's the kind of production thinking we build at InfraThrone - where outages aren't just explained.
They're experienced.
Discussion
to read and post comments.