ChatGPT caída spikes: check error rate, p95, queue, cost

A search spike is a symptom

When outage searches spike, the trade-off is speed versus spend: reroute or scale to cut latency, or degrade and pay less. Failed requests equal error rate times traffic, wait time grows with queue depth, and spend grows with tokens times price. The arithmetic makes the decision easier.

A single observation without context can mislead an analyst because of gaps or bias. Down Detector reported problems in four popular chatbots beginning around 15:00 Spain peninsular time. OpenAI's official status page said it was experiencing problems and had serious errors in ChatGPT and Codex. The outage was reported to have started around 17:00 and not been fully restored until after 19:00, with Anthropic's chatbot described as the most affected. ChatGPT was reported as the first service to return to normal operation.

User reports are noisy. Down Detector data attributed 77% of reported ChatGPT problems to the chatbot, 10% to Codex, and 7% to the application. That split matters: a model-level failure can look like a product outage. Claude's outage was reported to affect Mythos 5.1, Fable 5.1, Opus 5, Opus 4.8, and Opus 4.6.

The same caution applies to capacity probes. On 28 February 2022, HTTP requests from Lviv, Ukraine increased 3-4X, and Cloudflare recognized the abnormal increase might be mislabeled as an attack, but other signals helped avoid that conclusion. In the same case, Cloudflare's DoS defense and mitigation systems did not flag an attack, helping the team avoid misclassifying the traffic spike. Two speed tests sharing a bottleneck can each see only half the true bandwidth, so capacity estimates need method-aware measurement before scaling or rerouting.

Inference serving is a major operational surface: AWS expects as much as 90% of workloads to become inference-related. The serving path is the first place to look. Status pages are useful, but they are not a substitute for your own telemetry. A vendor can acknowledge a problem while your users are already seeing timeouts. Your dashboard should answer: is the path failing, is it slowing, and is it costing more? If the answer is only cost, the incident is a budget problem, not a reliability problem.

Four serving signals separate outage from noise

The check is for the serving path, not just the model. The model may be fine while the gateway, queue, or token billing path is broken. Use the same time window for all four signals; a mismatch can make a slow queue look like a cost problem.

Run the four checks in this order; each is testable in a minute and points to a different failure mode. The order separates user impact from serving impact.

• Error rate. Compare current failures to baseline. Errors jump: the serving path is broken, not just slow.
• p95 latency. Check the slow majority, not the average. A rising p95 means users feel the queue before alarms fire.
• Queue depth. Watch pending requests and capacity headroom. Queue grows while error rate stays flat: you are near saturation.
• Cost per 1k tokens. Multiply token volume by unit price. Spend climbs with traffic: the fix may be routing, batching, or a smaller model.

When queue depth is not directly visible, infer it from latency and request rate. A rising p95 with flat errors is a queue building. When cost is not visible in real time, use token counters and unit price. The target is a spend rate you can compare to traffic.

Half of production AI deployments have trouble keeping latency acceptable at scale. Inference cost is the second-largest enterprise AI budget line after talent. Treat latency and cost as core serving signals, not afterthoughts.

The action follows the numbers

High error rate and high queue depth: reroute first. Low error rate, high p95, and rising queue depth: scale or add capacity. High p95 with flat queue depth: degrade by shortening context, reducing max tokens, or using a cheaper model. Error rate, p95, and queue depth stable, with only cost per 1k tokens rising: pay or renegotiate; do not buy latency you do not need.

Record the decision and the signal that drove it. Rerouted: note which route took the load. Degraded: note which quality knob changed. Paid: note the cost per 1k tokens before and after. A later incident becomes easier when the previous incident left a trail.