AI Provider Outage Plan: Fallback Models, Gateways, Contracts

When your AI provider goes down, your tool stops unless a tested second route is ready. A fallback model or gateway helps only if you have checked what it will and will not do. Between 1 September and 8 October 2026, the Claude and OpenAI status pages show 15 incident windows on their model APIs. Most ended within three hours. One narrow issue ran almost thirteen hours. This guide is for owners and operations leads who run AI tools on someone else's model. It picks up where our guide to what to do when an AI agent fails stops, at the provider layer.

Update, 28 October 2026: We re-checked Google's two SLAs, Anthropic's terms and error reference, MAS's guidelines page and the three gateway docs; all still match. One correction: a 429 on the Claude API can also mean your usage tier's monthly spend cap has been reached, not only a short-term rate limit.

How often do AI model providers go down, and for how long?

Often enough that a plan is not optional, and mostly for under three hours. We read two vendor status pages for 1 September to 8 October 2026 and kept incidents that list the model API, counted by start time. Claude's status page has ten with model errors or latency on the Claude API. OpenAI's status page lists about 40 incidents for September alone (39 by the feed's dates, 40 by start time), but only five in the period name its chat or responses components. Most hit ChatGPT, Codex or account tools. We kept only those naming those two API components, so that filter, not the vendor, sets the count of five.

The chart groups the 15 windows by length. The longest Claude window was 177 minutes on 3 September, when several models returned errors. The longest OpenAI window was narrow: 770 minutes for large-PDF errors in its Responses API on 6 October. The widest was 29 September, when OpenAI listed errors across ChatGPT and Codex as well as the API for 321 minutes.

Read the chart with care. Claude's windows run from first entry to resolved, OpenAI's from the start to the end of the affected component, so they differ. Anthropic put its 29 September impact at 14:00 to 14:59 UTC; the status-page window ran 126 minutes. Five OpenAI windows is a small sample, so read the chart for scale only. Set the narrow PDF issue aside and three of the other four OpenAI windows still ran two hours or more, so that one issue does not explain the gap. It still does not make either provider the safer pick.

Google's public incident feed lists seven incidents before 9 October 2026. Only one names the Gemini API: 118 minutes on 27 February. One incident is too few to estimate how often it fails.

One finding matters for the plan. By our count, the Claude and OpenAI windows overlapped once: a 19-minute Claude error window on 6 October fell inside the narrow OpenAI large-PDF issue. On 29 September the two broad events were about 85 minutes apart. Five weeks is a short record, and the overlap involved a narrow issue, so it is a hint, not proof. It points the same way as the plan: in this period the two did not often fail together, which is what a second provider is for.

What does an AI provider promise when it goes down?

Usually a monthly uptime target and a credit on a future bill; in some public terms, nothing at all.

Google Cloud's service level agreement for the Gemini Online Inference API on its Gemini Enterprise Agent Platform (the Vertex AI name remains in the URL), last modified 30 June 2026, lists, under "Monthly Uptime Percentage", the "generateContent and streamGenerateContent methods of Gemini Online Inference API on Gemini Enterprise Agent Platform" at "99.5%", with a footnote: "When used with the models designated for shorter availability listed in the table described in the applicable Documentation, the SLO’s Uptime Percentage will be 95%." The agreement calls each such figure a "Service Level Objective". Downtime counts only when more than 5% of valid requests return a server error for five or more consecutive minutes. A miss earns a credit of 10%, 25% or 50% of that month's bill for the service. The agreement calls this the "sole and exclusive remedy", and you must claim within 30 days with log files. Google's separate Gemini API Additional Terms, which cover Google AI Studio and the developer API, state no uptime promise, so this figure belongs to the Google Cloud route only. A 99.5% promise in a 30-day month allows 216 minutes of downtime before it is broken. In plain terms: a 3-hour outage can sit inside the promise and earn you nothing. Its Vertex AI platform SLA, last modified 12 February 2026, sets 99.9% for training and deployment, and for batch prediction: about 43 minutes.

Anthropic says less in public. Its commercial terms, effective 17 June 2025, open their warranty clause with "except to the extent expressly provided for in these terms" and then state that the services "are provided 'as is' and 'as available'". The page gives no uptime figure; a signed enterprise agreement may say more, so ask. OpenAI's site refused automated access, so we make no claim about its terms.

A credit is a share of your bill. It is not a share of your lost orders, and it does not restore a day's work.

What does a fallback model or gateway actually do?

A gateway or router sends a failed request to the next model on a list. It does not check that the next model will do the same job. If your tool runs through one, find out what it does when your main model fails. Three widely used tools show the pattern in their own documentation.

Four traps sit between that diagram and a working plan.

A different model is not a drop-in. The Claude API error reference shows why. Send a request that switches thinking off to Claude Sonnet 5.5 (released 28 September 2026) and it returns a 400 error, and four current models reject forced tool use. A fallback list that mixes models needs settings for each model, written down and tested.

Not every error is the provider's. The same reference says a 429 can mean you reached your usage tier's monthly spend cap, which "keeps failing until access resumes", and 401 and 402 point to your key and billing. A gateway that falls back on every error can hide a billing problem behind a costlier model. Fire it on provider-side failures: server errors, the 529 "overloaded" response and timeouts.

Quality and cost can change quietly. A fallback answer can be worse and still look fine. Log which route and model answered each request, as the Cloudflare header and OpenRouter response allow, so you can find the affected work. Google's Gemini troubleshooting guide advises retrying 429 and 503 errors with backoff and jitter, up to a maximum number of attempts, not switching models.

The gateway is another dependency. Cloudflare's postmortem of 18 November 2025 says its outage began at 11:20 UTC and core traffic "was largely flowing as normal by 14:30". The post does not mention AI Gateway, so we draw no link. The lesson is general: a layer added to reduce one risk is one more thing that can stop. Running the same model through another cloud, which the Claude API reference names for Amazon Bedrock and Google Cloud, is a different kind of fallback. It behaves most like the original, but it still needs its own test and contract. Any fallback provider is another place your customers' data goes, so settle data location and terms before the outage.

What would an outage cost your team?

The cost is the work nobody can do while the tool is down, minus what a tested fallback absorbs and what can wait. The what-if turns that into staff hours, the part you can plan for.

Compare the first two presets. With no fallback, 59 tasks need hand work and 27 are still undone when service returns. With a tested fallback taking 70%, 18 need hand work and none is left. You can set your own numbers in a minute. An untested one does not belong in that 70%.

What do regulators expect you to be able to show?

For Singapore's financial institutions, as of 7 October 2026: contingency plans with fallback options for high-risk AI, and a view of third-party concentration. This is general information, not legal advice. The guidelines set MAS's expectations for financial institutions; their suppliers may meet them as procurement questions.

On 7 October 2026 MAS published its Guidelines on Artificial Intelligence Risk Management for Financial Institutions. Sections 3 and 4 apply from 7 October 2027, and Sections 5 and 6, which hold paragraphs 5.3 and 5.11, are due by 7 October 2028. Paragraph 5.3 is the one this post is about. It asks for plans, not for tests; testing the fallback is our recommendation:

For an AI use case assessed as high risk, an FI should develop and implement contingency plans outlining fallback options, such as alternative systems or manual processes, to ensure business continuity in case of AI failure or unexpected behaviour.

Monetary Authority of Singapore, Guidelines on Artificial Intelligence Risk Management for Financial Institutions, paragraph 5.3, published 7 October 2026.

Paragraph 5.11 adds the provider side. The institution "retains primary accountability for its use of third-party AI", and should weigh concentration risk from "over-reliance on key third-party AI providers", contingency plans, and legal agreements with clauses such as "performance guarantees". If risk stays outside its appetite, it should consider "limiting or suspending the third-party AI service, or replacing the relevant third-party provider".

MAS's Business Continuity Management Guidelines of June 2022 already asked for service-level agreements with "specific and measurable recovery expectations" (paragraph 4.4) and plans for "unforeseen disruption, failure or termination of third-party arrangements" (4.5). Set against the Google Cloud Gemini SLA above, a bare uptime percentage is not a recovery expectation.

Which questions should you ask before you depend on a provider or gateway?

Ask what is promised, what is tested, and who acts on the day. The checklist below groups the questions that follow from the sources above. Tick what is true now.

The middle group is the hard one. A contract can be read in an afternoon, but a fallback test needs a test set, a few hours and someone who marks the answers honestly. Our guide to questions before buying an agent covers the contract side in more depth.

Where Origin Pi stands

We think a fallback is a governed change, not a configuration switch. It needs an owner, a test set, a note of where data goes, and a record of which model answered. Our AI governance work designs this layer with the client: the provider map, failover limited to provider-side errors, the confirm step before anything that commits the business, and the log that finds the work a fallback touched.

The manual path stays the last line. Neither a second provider nor a gateway helps when the model is up but quietly wrong, as our continuity guide explains.

Your first step: open the terms for your main AI provider and find, in writing, the uptime target, how downtime is measured, and what you receive if it is missed. Any that is missing is your first question.

Take the data with you

Every figure in this post is in one table, with its source, source date and the date we read it. If you reuse either file, please cite this post and link back to it.

• Data table (CSV, 4 KB)
• At-a-glance card (PNG, 62 KB)