First: is it actually down?
Two sources, in this order. Your own telemetry: a sudden spike of 500s, 529 overloaded responses, and timeouts across all Claude calls, on every key and endpoint, is an outage. Errors confined to one feature, key, or request shape are your bug wearing an outage costume. Then status.anthropic.comto confirm, remembering status pages typically lag your users’ pain by minutes. Alert on your error rate, not on the status page.
Decide the failure behavior per feature, in advance
- Critical, user facing: fall back to a second model or provider you chose ahead of time, with the prompt already tested there. Same provider first ladder: if
claude-sonnet-4-6is overloaded,claude-haiku-4-5often still responds. Cross provider second. - Nice to have:degrade honestly. “AI summaries are temporarily unavailable” costs you nothing and users forgive it. A spinner that never resolves costs you trust.
- Background jobs: queue and retry with exponential backoff plus jitter. No backoff means you extend the outage for yourself and everyone else, then trip rate limits on recovery.
The routing machinery for the first case, detecting failure and swapping the client cleanly, is the same machinery as cost based routing, covered in LLM fallback routing.
The fallback cost multiplier
Here is the part that shows up two weeks later on an invoice. Fallbacks usually route upward, to whatever reliable model is available, and the price gaps are not small. Current Anthropic rates per million tokens: Haiku 4.5 at $1 in and $5 out, Sonnet 4.6 at $3 and $15, Opus 4.8 at $5 and $25. A Haiku feature failing over to Opus runs five times the cost per call for the whole incident, and cross provider fallbacks can be worse. On a feature doing 100,000 calls a day, a $0.003 call becoming $0.015 is $1,200 of extra spend per outage day.
- Tag fallback traffic distinctly, for example
feature: 'summary-fallback', so the incident cost is one query, not archaeology. - Cap the fallback path. A per user spending cap that downgrades instead of blocking keeps the feature alive without an open ended bill; mechanics in per user spending caps for LLM apps.
- After the incident, compare the fallback window’s cost against baseline. That number is your budget for deciding whether better fallback engineering pays for itself.
What your cost tracking should do during an outage
A detail that matters when the outage is your tracker’s, not Anthropic’s: monitoring must never become the reason your product is down. Weckr fails open by design. If its API is unreachable, cap checks allow the call, and logging drops silently instead of blocking the request path. You trade a monitoring gap during the incident for the guarantee that a cost tool can never take your product offline, which is the only defensible default. The broader surprise bill playbook is in how to avoid surprise AI bills.
FAQ
How do I check if the Claude API is down?
Check status.anthropic.com first, then confirm from your own telemetry: a spike in 500 or 529 responses and timeouts across all your Claude calls is an outage, while errors on one endpoint or one key are usually your bug. Alert on your own error rate rather than the status page, because your users feel your errors minutes before status pages update.
What should my app do when Claude is unavailable?
Decide per feature, in advance. Critical user facing features fall back to another model or provider. Nice to have features degrade gracefully with a clear message. Background jobs queue and retry with exponential backoff and jitter. The one wrong answer is hammering retries with no backoff, which extends the pain and can trip rate limits when the API recovers.
Does falling back to another provider change my costs?
Often dramatically, and nobody watches it during an incident. A fallback from claude-haiku-4-5 at $1 and $5 per million tokens to claude-opus-4-8 at $5 and $25, or to a pricier rival model, multiplies cost per call roughly five times for the duration. An outage that lasts a day on a high traffic feature can quietly add hundreds of dollars. Track fallback traffic separately so the incident bill is visible.
What happens to my cost tracking during an outage?
Depends on the design. Weckr fails open on purpose: if its API is unreachable, cap checks allow the call and logging silently drops rather than blocking your traffic, because a monitoring outage must never take your product down. The tradeoff is a monitoring gap during the incident, which is the right tradeoff and worth knowing about.
Should I build multi provider fallback preemptively?
For your one or two critical AI features, yes: same prompt, a second provider client, and a routing wrapper is a day of work that turns a provider outage into a non event. For everything else, graceful degradation is usually better than doubling your provider surface. Match the engineering to how much each feature failing actually costs you.
Keep reading
Know what the incident cost you
If your cost data is per user and per feature, an outage postmortem includes the money: what the fallback window cost, which features drove it, and whether any user’s cap fired. Weckr records exactly that, with caps that downgrade instead of denying service. See it on the live demo, or start with the AI cost and margin guide.