Claude Outage: Two of October's Incidents Were Billing, Not Servers

In short: most "Claude outage" searches are people checking whether Claude is down. For that, the answer is status.claude.com. This post is about the other question: what happens to your product when it is. Two of the incidents on Anthropic's status page in early October 2026 had nothing to do with servers or models. They were billing faults that refused requests from organisations that had paid. We had the same failure on our own AI account in September, for an hour, and nobody noticed until a job failed. Below: what happened, why billing faults are the outage nobody plans for, and the five things we now do in every app that calls an LLM.

---

What happened in October

All of this is from Anthropic's status page, as reported by Mixed News. Times are UTC.

The 7 October entry is the interesting one. In Anthropic's words, "some organizations [were] incorrectly paused for having reached their spend limit". Because the limit applies to the whole organisation, one faulty check refused requests on the Claude API, Claude.ai, Claude Code, Claude Security and Claude Cowork at once. The status page gave no start time, no count and no cause.

The model outages lasted 20 to 30 minutes. The two billing incidents lasted hours.

Why a billing fault is worse than a server outage

A server outage looks like an outage: timeouts, 500s, 529 "overloaded". Most code retries those, and retrying is right, because they clear on their own.

A billing fault looks like your fault. The API answers fast and clearly: a 402, or for a spend-limit pause, a 429 with the code enforced_spend_limit_reached. Three things then go wrong in most apps:

1. The retry loop keeps going. A 429 usually means "slow down", so the code backs off and tries again, forever. The balance does not refill between attempts.
2. Nobody gets paged. The provider's status page may be green. Your monitoring sees a high error rate on one dependency, if it sees anything.
3. The fix is not technical. Someone with access to the billing console has to look. At night or on a weekend, that can be hours.

It happened to us in September

Our AI features (document extraction, CRM assistants, the menu editor we built for a wine-list product) run through one service that calls models from several providers via a single OpenRouter account. On 21 and 22 September 2026, that account's balance ran out. On the 22nd, production returned 402 "insufficient credits" for an hour, from 06:04 to 07:06 UTC, before anyone looked. Every AI path was down at once, because they all share one balance.

It was worse than it needed to be. Our retry loop made three attempts per request against an error that could not clear, and logged over 1,000 lines for roughly a third as many requests. The first anyone knew of it was a Sentry error from a job that had already failed.

That is the same shape as Anthropic's 7 October incident, seen from the customer side.

What we changed

Stop on errors that cannot clear. A 401 (bad key), a 402 (no credit), or a model slug that no longer exists fails every call the same way. Our code now recognises them, from the status code or from the provider's error body, and gives up on the first attempt instead of the third. It then fails loud: an error in our logs, which becomes a Sentry alert.

Alert before the money runs out, not after. A background check reads the account balance every hour and raises an alert when it drops under $25. It is a poll, not a startup check, because a balance is fine at deploy time and gone four days later. The alert message is fixed, so Sentry groups every firing into one issue that keeps ringing instead of a new issue per hour.

One model per task, in configuration. Each task names its model in a setting: a fast model for the CRM assistant, a stronger one for writing summaries, a vision model for wine labels. Moving a task to another model or provider is a configuration change, not a code change. A model we reference that the provider retires is caught at startup.

What we have not done yet. All our models still share one account, so a spent balance is still a total AI outage, just a shorter and louder one. We do not yet fail over automatically to a second provider or account. Switching is a configuration change someone makes, not something the system does on its own. We say it here because a resilience list with no gaps is a sales pitch.

Five checks for any app built on one LLM provider

If your product calls Claude, GPT or Gemini in production, these are the questions we would ask in a review:

1. Which errors does your code retry? Overloaded and timeout: yes, with backoff. Bad key, no credit, spend limit reached, unknown model: no. Read the error code, not just the HTTP status: a 429 can mean either.
2. Who gets told, and how fast? An outage of your AI provider should page a person, not just raise an error rate on a dashboard nobody watches at 6 a.m.
3. Do you watch the balance and the spend limit? Poll them. Alert with enough margin to act. A spend limit set to protect you from a runaway bill is also a switch that can turn your product off.
4. Can a task move to another model without a release? Keep the model per task in configuration, and test the second choice before you need it: prompts tuned for one model often degrade on another.
5. What does the user see? Wherever the business process can continue without the AI step, let it: save the document for later processing, fall back to the manual form, queue the request. An error page is the worst option.

Related: cost efficiency in LLM production, smaller LLMs, same results, and the AWS UAE outage and multi-region disaster recovery.

Read next: AWS outages in 2025 and 2026, how much it costs to build an AI agent.