What Happens When the AI Provider Has an Outage?

This one's speculative — a thought experiment about design principles, not a report on something I've built.

A dependency you cannot patch

A feature built on a third-party model API has a dependency most software teams aren't used to reasoning about: when it goes down, there's no local fix, no rollback to a prior internal version, nothing to patch. The outage is entirely outside the system's control, and the only thing actually within control is how the system behaves while it's happening.

The default failure mode is usually the worst one

Without deliberate design, a feature that depends on an AI call tends to fail as a spinning loader or a generic error when the provider is down — the least helpful possible failure, because it gives the person using it no information and no path forward, at exactly the moment they need one.

Design the degraded state on purpose

A well-designed AI feature has an explicit, deliberately chosen fallback for provider downtime: a simpler deterministic version of the same function, a clear message that sets expectations honestly, or a queued-for-later behavior that doesn't block the person in front of it. Which fallback is right depends entirely on the feature, but having thought about it in advance, rather than discovering the gap live during a real outage, is the actual differentiator.

Test the outage, not just the happy path

The only reliable way to know a fallback actually works is to simulate the provider being unavailable and watch what the system does — the same discipline as testing a database failover, applied to a dependency that's arguably less predictable and less within your control than a database ever is.

I'm Jesse Myers — Marine veteran, 32 years in enterprise IT, now building production AI systems. This site is where I write about what I've actually built, and occasionally about ideas I haven't built yet but think are worth taking seriously.