When Your AI Provider Goes Down, What Stops?

On the evening of August 16, Anthropic confirmed that Claude went offline across its web app, its coding tools, and its developer platform for about forty-two minutes. As infrastructure incidents go this one is unremarkable. It was short, it was acknowledged, and it was fixed. The reason to pay attention is not the outage. It is the question sitting behind it, which almost no business that now uses AI every day has actually answered: during those forty-two minutes, what in your operation would have stopped?

The dependency nobody approved

AI dependency rarely arrives through a decision. It accumulates. Someone starts drafting proposals with it, then it becomes the only way proposals get drafted. A chat assistant goes on the website as an experiment and quietly becomes the front door for enquiries. A workflow that used to have a person in the middle gets tidied up, and the person is no longer in the middle. Nobody signed off on making the business dependent on a third party being available, because at no single point did it look like that decision. The result is that the exposure is real and undocumented at the same time.

Three buckets, one hour

The useful exercise is small. List every place AI touches your business and sort each one into three columns.

Bucket	What an outage means	Action needed
Convenience	Someone waits or does it the old way	None
Degraded	Work continues, slower and rougher	Keep the old template usable
Stopped	The process halts, customers may notice	Needs a real fallback

The pattern is consistent across the businesses we work with. Most items land in convenience, which is genuinely fine. One or two land in stopped, and they are almost never the ones the owner expected, because the stopped items are the ones where AI was working so smoothly that the human step got removed as tidying up rather than as a decision.

The manual path test

For everything in the stopped column, ask one question. Can a person do this today, without the tool, following instructions that exist in writing? Not in principle, and not by asking the employee who happens to remember how it worked eighteen months ago. The honest answer is often no, and the reason is usually mundane: the old template was deleted, the old checklist was never updated, or the process was rebuilt around the tool so completely that the previous version no longer applies. Restoring that path is cheap when you do it deliberately and expensive when you do it during an outage.

Customer-facing failure is a different category

There is one dependency worth separating out. If AI answers your phone, replies to enquiries, or greets people on your website, an outage is not an internal inconvenience. It is a customer experiencing your business as broken, and unlike an internal delay you cannot absorb it quietly. The minimum standard is that anything customer-facing degrades visibly rather than silently: a contact form that appears when the assistant cannot respond, a phone path that reaches a person, a clear message rather than a spinner. Silence is the worst possible failure mode, because customers read it as neglect rather than as a technical fault.

A second provider is the second answer

The instinct after an outage is to add a backup provider, and sometimes that is right. It makes sense where downtime carries real cost and the work is generic enough to move between models, such as drafting or summarising. It makes much less sense where you have built prompts and integrations around one provider's behaviour, because an untested backup fails at exactly the moment you need it. Hedging is a genuine strategy, and we make the fuller case in not marrying one AI model, but it belongs after you know your exposure rather than instead of knowing it.

Reliability is a moving target

Treat this as maintenance rather than a one-off. Dependencies deepen quietly as tools get better and as people trust them more, so the map you draw today will be wrong in six months, and it will be wrong in the direction of more exposure rather than less. Reviewing it twice a year alongside the rest of the upkeep an AI build genuinely needs is enough. Forty-two minutes was a cheap reminder. The businesses that learn something from it are the ones that spend an hour answering a question they have never been asked.

Frequently Asked Questions

What happened?

Anthropic confirmed an outage on the evening of August 16 that took Claude offline across its web app, its coding tools, and its developer platform for roughly forty-two minutes before service was restored. By the standards of cloud infrastructure that is an unremarkable event, handled properly and communicated openly. It is worth paying attention to anyway, not because forty-two minutes is a catastrophe, but because most businesses now using AI daily have never asked themselves the obvious follow-up question: during those forty-two minutes, what in our operation would have stopped?

Why does a short outage matter?

Because the length is not the point. Outages of this size happen to every provider, including the largest and most reliable, and they will keep happening. What matters is whether the interruption is an inconvenience or a stoppage, and that depends entirely on how AI is wired into your work. If a member of staff switches to doing something else for half an hour, you have an inconvenience. If your quoting stops, your inbound enquiries go unanswered, or a customer-facing chat assistant simply stops responding, you have an outage of your own that your customers experience directly.

How do we work out our exposure?

Write down every place AI touches your business and sort each one into three buckets. Convenience means someone waits or does it the old way, and nothing external is affected. Degraded means the work continues but slower or rougher, such as a person writing a first draft themselves. Stopped means the process genuinely halts, usually because AI sits inside an automated chain with no human standing by. The exercise takes under an hour, and the surprise is almost always the same: one or two things that quietly moved into the stopped column without anyone deciding they should.

What is the manual path test?

For each process in the stopped column, ask one question: can a person do this today, without the tool, using instructions that exist in writing? Not in theory, and not by asking the one employee who remembers how it worked before. If the answer is no, the AI has become a single point of failure and nobody chose that. Restoring the manual path is often as simple as keeping the old template, the old checklist, or the old form accessible rather than deleting it, which costs nothing and is the difference between a slow hour and a lost day.

Should we use a second AI provider as backup?

Sometimes, but it is the second answer rather than the first. Keeping a second provider available makes sense for a process where downtime has real cost and where the work is generic enough to move, such as drafting or summarising. It makes far less sense where you have built prompts, integrations, or fine-tuned behaviour around one provider, because the backup you never test will not work when you need it. For most small businesses the honest order is: know your exposure, restore the manual paths, then add a second provider only where the maths justifies the extra complexity.