AI outages feel like a new problem.
They aren't. They're the oldest problem we have, wearing this season's label.
Listen to how the sentence has changed over the years.
Twenty years ago: "The database is down."
Ten years ago: "us-east-1 is having issues."
Five years ago: "GitHub Actions is unavailable."
Today: "The model provider is down."
Same sentence. Different noun. The failure mode underneath it never moved. You outsourced a critical capability to a service you don't control, and one day that service wasn't there.
It was never an AI question
The conversation everyone wants to have is whether AI is reliable. It's the wrong conversation, because nothing is perfectly reliable. Your database isn't. Your cloud provider isn't. Your payment processor isn't. Reliability is never a yes or no. It's a number with more nines than you'd like to admit and fewer than you'd like to have.
The question that actually tells you something is older and less exciting:
What happens to your business when the dependency disappears?
That question doesn't care whether the dependency is a Postgres instance, a region, a CI runner, or a frontier model. It's a distributed systems question, and it has been the same question the whole time. AI just made it fashionable to ask again.
Every external dependency is the same trade
When you reach for someone else's service, you're making a trade you've made a hundred times before. You get faster delivery and a lighter operational load. You give up control, and you take on the risk that the thing you now depend on can fail in ways you can't fix and can't always see coming.
That trade is usually correct. I'm not arguing against dependencies. Self-hosting everything to avoid depending on anything is its own kind of failure, the kind where you spend your whole budget rebuilding infrastructure that someone else operates better than you ever will.
AI APIs are simply the newest line item on a list every engineer already knows by heart:
- A database dependency.
- A cloud provider dependency.
- A payment processor dependency.
- An identity provider dependency.
Nobody panics about those anymore, because we've built decades of resilience patterns around them. Failover. Degraded modes. Retries. Circuit breakers. Runbooks. The patterns exist and the muscle memory exists.
The only thing genuinely new about the AI version is that most organizations haven't applied any of those patterns to it yet. The risk isn't novel. The negligence is.
The questions you'd already ask about anything else
If a vendor told you their service was now load-bearing for your engineering, your support, your content, and your customer service all at once, you'd interrogate it. You'd ask the boring resilience questions you ask of every other dependency. Ask them here too.
- Can you fail over to another provider? If the answer requires a rewrite, you don't have a dependency, you have a single point of failure with good marketing.
- Can you operate in degraded mode? A slower, dumber, cheaper fallback that keeps the lights on beats a perfect system that's simply off.
- Can a human take over temporarily? Manual and slow is a state your business can survive. Stopped is not.
- Can you self-host if you have to? You may never pull the lever. Knowing the lever exists changes every negotiation and every outage.
- Is the AI augmenting the workflow, or is it the workflow?
That last one is the dangerous question, so sit with it.
When the dependency becomes the workflow
There's a line every dependency can cross, and most resilience failures happen on the far side of it.
On the near side, the dependency augments the work. When it's gone, things get slower, clumsier, more manual. Annoying. Survivable. The outage is an inconvenience, and inconveniences have a way of ending.
On the far side, the dependency is the work. There's no slower path because the path was deleted when the automation arrived. When it's gone, nothing happens. Not slowly. Nothing.
When the AI is the workflow, an outage stops being an inconvenience and becomes a business interruption.
This is the same thing I keep saying about recovery being the system: the interesting part of any architecture isn't how it behaves when the dependency is healthy, it's what's left when the dependency is gone. A workflow with no degraded mode isn't efficient. It's just an outage that hasn't been scheduled yet.
And it's the same organizational trap I wrote about in why most reliability problems are organizational problems. The model going down is the proximate cause. The real cause is that someone decided to route four critical functions through a single external dependency and nobody owned the question of what happens when it blinks.
The face is the only thing that changed
Strip away the novelty and the framing is identical to every dependency conversation we've had since the first time a remote service we relied on went dark.
The capability is critical. The provider is external. Control is partial. Failure is inevitable, eventually, in some form. The only honest engineering response is to decide in advance how much of your business you're willing to let stop when it does.
AI didn't introduce that problem. It inherited it. The vendor changed, the noun in the sentence changed, the demo got more impressive. The distributed systems problem underneath it is exactly the one we've been solving, badly and then better, for twenty years.
The face changed. The dependency didn't.
The one-line version
An AI outage isn't a new kind of failure. It's the same dependency risk you've always had, and the only question worth asking is the one you'd ask of any critical service: what stops when it's gone, and have you decided that on purpose?