Single points of failure: What happens when OpenAI (or AWS) goes down?

When OpenAI's API went down in November 2023, it took thousands of production applications with it for over 4 hours. When AWS us-east-1 had its major outage in December 2021, it knocked out Netflix, Disney+, Slack, and hundreds of SaaS products simultaneously. That’s what centralized infrastructure looks like under immense load. These are case studies in why your GPU compute should never sit in just one hyperscaler basket. Doubly so for AI startup or LLM research project that can’t afford that downtime.  

If your AI workload routes through a single provider, you inherit their failure modes. One misconfigured load balancer, one DDoS event, one botched deployment becomes your emergency. The math is unforgiving: a provider with 99.9% uptime still hands you 8.7 hours of downtime per year. If your pipeline depends on three such services in sequence, you compound to roughly 26 hours. For inference workloads running 24/7, that's real revenue and real user trust. Let’s look a bit closer at the mechanics of what happens when you hyperscaler-run compute goes down. 

What centralized outages actually cost

The direct cost is easy to calculate. What’s far harder to measure is all of the damage that snowballing: SLA penalties, support escalations, emergency engineering hours, and customer churn that never shows up on an incident postmortem.

A mid-size company running 50,000 API calls/day at $0.002 per call loses roughly $400 in direct costs during a 4-hour OpenAI outage. However, the engineering time spent on incident response typically runs 10–20x that figure. A larger enterprise with $50,000/month in API spend and a 99.9% SLA can expect to eat nearly $600 in guaranteed downtime costs annually, before any penalty clauses trigger.

The less-quantified cost is model dependency. If OpenAI changes its pricing, deprecates a model version, or shifts its rate limits, you adapt on their schedule, not yours.

How distributed GPU compute fixes the failure profile

Decentralized GPU networks are built around one major assumption: that individual nodes fail. So instead of routing all traffic through a single data center, these networks distribute workloads across hundreds of independent suppliers, each of which is running verified hardware, all of them replaceable without a service interruption.

This isn't just redundancy in the traditional sense (active-passive failover). It's structural: no single node, region, or operator controls enough of the network to cause a systemic outage. When one supplier goes offline, the scheduler re-routes to the next available node, typically within seconds.

A centralized GPU provider failure is essentially binary: you're either up or you're down. With a distributed network, failure is more probabilistic, in that individual nodes degrade but the aggregate service continues.

Running resilient inference on VOLT

VOLT's network includes GPU suppliers across North America, Europe, and Asia-Pacific. It features a scheduler that treats node availability as a dynamic variable instead of static infrastructure. After you submit a job for compute, VOLT finds capacity. If a node drops mid-job, the scheduler reassigns it for you.

What do the costs look like in the real-world? Let’s imagine 1,750 H100 SXM5 GPU-hours/month. The cost breakdown looks something like this:

• AWS p4d.24xlarge (8× A100 80GB) – ~$32.77/hr → $24,000/month for equivalent throughput
• VOLT H100 SXM5 – $2.45/hr → approximately $4,287/month for the same 1,750 hours

The cost savings works out to about $19,700 per month, with no single-region dependency. Those $19,700 in saved funds generate a meaningful amount of redundancy architecture (multi-provider fallback, caching layers, request queuing) that a team paying AWS rates often can't justify.

Why VOLT

Think of VOLT as selling default architecture instead of redundancy. The network boats thousands of verified GPUs across more than 138 countries. There's no us-east-1 equivalent, no single region that when it sneezes takes the whole network down. 

For teams that have been burned by centralized API outages, the most important take away is that you are in control of your compute, not the hyperscaler. 

On VOLT, you're not dependent on one vendor's deployment schedule, rate limit policy, or pricing decision. You pick your GPU type, your cluster region, your job duration. H100 PCIe at $1.49/hr, H100 SXM5 at $2.45/hr, A100 80GB SXM4 at $1.65/hr are all published rates, so you’ll never have to negotiate an enterprise contract that can change on a 90-day notice.

VOLT’s network also runs verifiable hardware attestation. This way you know the GPU you're being billed for is the GPU actually running your job. What this amounts to is a fundamentally different accountability model than black-box cloud instances where you're trusting the hyperscaler’s utilization math. And, really, why should you trust them?

For production inference workloads, the question isn't whether centralized providers will have outages. They most certainly will, and there is nothing you can do about it. 

What you can do is ask yourself the real question: is it time to switch to distributed GPU provisioning, so your AI infrastructure can seamlessly absorb those outages without going offline. Yes, it is.

---

Related Questions

Q: How often do major AI APIs like OpenAI actually go down?

OpenAI's status page shows multiple incidents per month, ranging from elevated error rates to full API unavailability. In 2023 alone, there were several incidents exceeding 2 hours of degraded or unavailable service. AWS reports fewer total outages but larger blast radius when they occur. The December 2021 event affected over 100 downstream services simultaneously. For any workload where uptime is contractual, "major providers sometimes go down" needs to factor into architecture decisions, not just incident response plans.

Q: What's the difference between cloud redundancy and decentralized compute for GPU workloads?

Traditional cloud redundancy means running the same workload in two AWS regions and paying double. If AWS itself has a control-plane issue — which has happened — both regions degrade together. Decentralized compute means your workload spans suppliers with no shared infrastructure dependency. A node failure in Frankfurt doesn't affect capacity in Dallas or Singapore because they're operated by different entities on different hardware stacks.

Q: Can I use VOLT as a fallback for OpenAI or AWS outages?

Yes, and this is a common use pattern. Teams run primary inference through a centralized provider and configure VOLT as a fallback for raw GPU capacity when the primary is degraded. Because VOLT pricing is on-demand with no minimum commitments, the standby cost is near zero until it's needed. The more common migration path is running batch and fine-tuning workloads on VOLT at cost savings, then using those savings to fund the redundancy layer.

Q: Does distributed GPU compute introduce latency compared to centralized providers?

It depends on job type. Distributed networks are competitive or even better when it comes to batch inference, fine-tuning, and training runs, latency to first token matters less than throughput and cost. For real-time inference with sub-100ms SLA requirements, region selection matters. VOLT lets you filter for clusters in specific geographies to minimize network hops. Latency is a tunable parameter, not an inherent disadvantage.

Q: How does VOLT handle node failures mid-job?

The scheduler monitors node health continuously. If a node drops during a job, the scheduler marks the affected work units for re-execution on available nodes. For stateless inference jobs, this is transparent to the caller. For long-running training jobs, checkpointing to persistent storage is the standard pattern — the same approach used on any distributed compute platform. VOLT's documentation covers checkpoint configuration for common frameworks including PyTorch and JAX.