Learning center

Automatic AI provider failover without silent policy drift

See how health circuits, quota cooldowns, capacity evidence, and bounded fallback keep an outage from becoming an uncontrolled model change.

For Platform engineering, SRE, DevOps, and system administrators · Updated September 17, 2026

Detect the failure

The gateway reads provider results from governed requests. A 429 response or an exhausted-quota header pauses that target for a set period. Repeated upstream server failures open a short health circuit. A later success may clear the circuit. It does not erase a separate quota cooldown.

Keep every gateway instance in sync

Each tenant's cooldown and circuit records live in the shared control store. They contain operational state, not prompts or responses. Every gateway instance reads the same state, so the next request avoids a target that is already known to be unhealthy.

Select an approved fallback

First, the route excludes targets that are paused, cooling down, unhealthy, incompatible, over capacity, blocked by policy, or over budget. It then applies the configured priority, weight, or estimated-cost rule to the eligible list.

  • Each target has a limit on attempts and timeouts.
  • The request ledger records the skipped target, the fallback reason, and each provider attempt.
  • An operator can drain a target and restore it later while keeping its configuration.
  • If no valid alternative remains, the gateway returns an explicit error and makes no additional provider call.
Put it into practice

Test the failure path before relying on it.

Trigger a simulated outage and inspect the fallback reason, eligible target, and resulting evidence while all provider traffic stays simulated.

Create a free workspace Try the Test LabTalk with us