AI provider outages disable customer-facing features without warning. The practical response is not to hope for better uptime - it is to design for the outage from the start. This article covers the fallback patterns that reduce user impact when your primary AI API is unavailable, and the decisions you need to make before an outage happens.
AI API Outages Are Normal Infrastructure Events
Anthropic (status.claude.com), OpenAI, Google Cloud and other providers publish public status pages with incident history that anyone can read. As an example, the Claude status page, when we checked on 19 October 2026, listed incidents on 5, 6, 7 and 13 October. Any provider can have incidents, so plan for them. For scale, a 99.9 percent availability target allows about 8.8 hours of downtime per year (0.1 percent of 8,760 hours); check your provider's actual SLA terms rather than assuming any figure.
If your product has a customer-facing feature that calls an AI API on every user action - a chatbot, a document summary, an AI-assisted form - then a provider outage of several hours is a several-hour outage of that feature. For most products, that is unacceptable. The answer is a fallback plan.
Three Fallback Approaches
Fallback strategies range from full redundancy to graceful degradation. Which one is appropriate depends on how critical the AI feature is to your core user journey.
Approach 1: Multi-provider routing
You maintain API integrations with two or more providers - for example, Anthropic Claude as primary and OpenAI GPT as secondary. Your application layer detects a failure on the primary (a 5xx error, a timeout, or an explicit outage signal from the provider status API) and routes the request to the secondary. This approach keeps the feature running but requires prompt engineering and output validation for both providers, because the same prompt does not always produce the same quality of response on different models. Model behaviour differences matter - a feature designed for one model may need tuning to work well on another.
Approach 2: Cached or pre-generated responses
For features where the output is predictable from a finite input space - frequently asked question answers, summary templates, classification results on known categories - you can pre-generate responses and cache them. During an outage, the cache serves as the fallback. This works well for high-volume, low-variance use cases such as product description generation or FAQ chatbots. It does not work for open-ended generation or personalised outputs.
Approach 3: Graceful degradation
For features where neither multi-provider routing nor caching is practical, the right fallback is to disable the AI feature cleanly and let the user complete their task without it. A chatbot that shows 'AI assistant is temporarily unavailable - please contact support' is far better than an error page or a spinner that never resolves. The user can still use your product; they just lose one enhancement. Designing for graceful degradation requires that the AI feature be genuinely additive to the user journey, not load-bearing for core functionality.
The Decisions You Need to Make Before an Outage
The time to design your fallback is during development, not at 11pm when a provider goes down. These are the decisions that need to be made in advance.
- Is the AI feature load-bearing or additive? Load-bearing means the user cannot complete a core task without it. Additive means the task can be completed without AI, just less conveniently. Load-bearing features require a redundant provider or a non-AI fallback path. Additive features can gracefully degrade.
- What is your failure detection mechanism? You need to know when the provider is down. Options include checking the HTTP response code of each API call, polling the provider's status API on a schedule, or subscribing to the provider's status page updates (the Claude status page offers email, Slack, webhook, Atom and RSS subscriptions). A dashboard that your team watches is not sufficient - you need an automated alert.
- What does a degraded experience look like for the user? Design the UI state for the degraded experience before an outage forces you to improvise. The message shown to users, the alternative path they can take, and whether the feature is hidden or disabled should be decisions made calmly in advance.
- What is your failover logic? If you use multi-provider routing, define the trigger conditions: after how many consecutive failures do you fail over, what is the retry backoff strategy, and how do you return to the primary once it recovers?
- How do you test the fallback? Run a planned failure drill in your staging environment where you simulate a provider outage by blocking the primary API. Confirm that the fallback path activates correctly, the user sees the right message, and your monitoring alerts fire.
Circuit Breakers: a Pattern Worth Knowing
The circuit breaker pattern wraps a risky remote call and stops making it once failures pile up. In the context of an AI API, a circuit breaker works like this: your application tracks the error rate of calls to the AI provider over a rolling time window. When the error rate exceeds a threshold - say, 50 percent of calls failing in the last 60 seconds - the circuit 'opens' and your application stops calling the provider for a short period, instead immediately returning the fallback response. After a timeout, the circuit 'half-opens' and allows a single test call through. If it succeeds, the circuit closes and normal operation resumes.
Martin Fowler notes that breakers reduce resources tied up in operations likely to fail, and give a struggling service room to recover. For your users the benefit is lower latency, because they do not wait for a timeout on every request. Libraries implementing this pattern exist for most server-side languages. It is worth implementing for any high-volume AI feature.
Cost and Billing During Failover
Multi-provider routing introduces a billing consideration: if your primary provider is down for several hours and your secondary handles all the traffic, your secondary provider bill for that period could be significantly higher than expected. This is especially relevant if your primary provider is less expensive than your secondary. Keeping AI API spend capped and monitored becomes more important when you have an active failover, because a spike in secondary traffic is expected and should not trigger alarm - but an unexpected spike after the primary recovers might.
Set per-provider spend alerts in addition to your aggregate alert. If the secondary is handling more than its expected share for more than an hour, that is a signal worth investigating even if total spend looks normal.
Monitoring and Observability for AI Features
Your standard application monitoring should include AI API call success rates as a metric, not just as noise in your general error logs. Track error rates by provider and by feature. A dashboard that shows 'AI assistant chatbot: 98.7 percent success rate' versus 'AI summary: 34 percent success rate' gives your team the information to respond before users start complaining.
Add provider latency as a metric alongside success rate. Some incidents show as elevated latency before they show as failures. A p95 latency spike on your AI provider calls is an early warning signal that the provider may be struggling, giving you time to fail over proactively rather than reactively.
A Practical Checklist
- Identify every customer-facing feature that calls an AI API and classify it as load-bearing or additive.
- Subscribe to status pages or RSS feeds for every AI provider you use: Anthropic (status.claude.com), OpenAI (status.openai.com), Google Cloud (status.cloud.google.com for Vertex/Gemini).
- Design the degraded UI state for each load-bearing AI feature and build it before you need it.
- Implement a circuit breaker or at minimum a timeout with a specific fallback action on every AI API call.
- Test your fallback path in staging by blocking the primary provider API and confirming correct behaviour.
- Set per-provider spend alerts that distinguish normal failover traffic from unexpected usage spikes.
- Add AI API success rate and p95 latency to your monitoring dashboard.
If you are building a customer-facing AI feature and want to understand how to design the fallback architecture before you write the first line of code, book a scoped AI feature review with Zovintra. We can review the integration design and the fallback plan before it becomes a production problem.
Common questions
What should I do when my AI provider has an outage?
Design for it in advance. Three fallback approaches are multi-provider routing, cached or pre-generated responses, and graceful degradation, where the AI feature is disabled cleanly so users can still complete their task. Which fits depends on how critical the AI feature is to your core user journey.
What is a circuit breaker for an AI API?
A circuit breaker wraps a risky remote call and stops making it once failures pile up. When the error rate crosses a threshold, the app stops calling the provider for a short period and returns the fallback response immediately, then lets a single test call through before resuming normal operation.
Can someone review my AI feature's fallback plan before launch?
If you are building a customer-facing AI feature, the fallback architecture is best designed before the first line of code. Zovintra offers a scoped AI feature review that looks at the integration design and the fallback plan before it becomes a production problem.
Sources
- Claude Status - Anthropic, accessed 19 Oct 2026
- OpenAI Status - OpenAI, accessed 19 Oct 2026
- Google Cloud Service Health - Google Cloud, accessed 19 Oct 2026
- CircuitBreaker - Martin Fowler, 2014
