On June 10, 2025, OpenAI acknowledged a problem at 2:36 a.m. Eastern. ChatGPT, the API platform and Sora were degraded for more than ten hours before normal service resumed. Every business that had built a daily process on top of them spent that day doing the work by hand, or not doing it.
That outage was not unusual in kind, only in length. Status pages for every major AI provider show incidents most months. What has changed is how many businesses now have AI in the operational path: intake, documentation, claims, reconciliation, client correspondence. When the model is part of how the work gets done, the provider's availability becomes your availability.
The June 10, 2025 incident, as reported
Per Tom's Guide's live coverage: reports began around 2:45 a.m. ET, OpenAI's status page listed a partial outage with elevated error rates and latency, ChatGPT showed 21 affected components and the API platform 14, and the outage lasted over 10 hours before normal service resumed.
What actually stops
It depends on how deep the dependency goes, and most businesses have not mapped it.
- Someone's personal assistant goes quiet. A lawyer who uses a chatbot to draft emails writes them the old way. Annoying, not operational.
- A workflow stalls. The intake summaries that the front desk relies on are not produced. The reconciliation that runs at 6 a.m. did not run. Someone notices at 9, and the day is now behind.
- A customer-facing system fails. The AI chat on the website returns errors. The automated phone intake hands every call to voicemail. Clients see it before you do.
- A compliance clock keeps running. A closing does not reschedule because a vendor had an incident. Claims go out on a cycle. Wire deadlines and filing dates are hard-edged.
The further down that list your business sits, the more a provider outage costs you, and the less control you have over when it ends.
The three ways to handle it
1. Accept it and write a fallback
Document the manual procedure for every AI-dependent step and make sure staff can run it. This is the minimum, and most businesses have not done it. It is what hospitals do for every other system: downtime procedures exist because downtime hurts patients.
2. Multi-vendor
Route to a second provider when the first one fails. It works for simple API calls. It doubles the number of vendors holding your data, doubles the contracts, and does nothing for an outage that hits the network between you and both of them.
3. Run the routine tier on your own hardware
Dedicated local models absorb roughly 60 percent of a typical office's AI workload: reading, sorting, extracting, drafting, reconciling. If those run on a machine in your building, a bad day in someone else's data center is not a bad day in your office. The remaining tier, the hard reasoning tasks, can still call a frontier model, with a sanitization step and a documented list of which tasks are allowed to. When that provider is down, only that tier waits.
| During a provider outage | Cloud-only | On-site routine tier |
|---|---|---|
| Document intake and extraction | Stops | Runs |
| Daily reconciliation and gates | Stops | Runs |
| Transcripts to action items | Stops | Runs |
| Hard reasoning escalations | Stops | Waits, flagged to a person |
| Who decides when it comes back | The vendor | You |
A question to ask this week
Make a list of every place AI touches the work in your business. Next to each, write what happens if it returns errors for ten hours on a Tuesday. If the answer is "someone does it by hand," write down who and confirm they still know how. If the answer is "it does not get done," that is the step to move on-site first.
Uptime decided in your building, by hardware you own, is the only kind you control.
The broader argument, including the six categories of operation that cannot accept imported downtime, is in the reliability piece.