The provider is a dependency, not a guarantee
Model providers publish status pages for a reason: APIs go down, degrade, or return elevated error rates like any other hosted service. Anthropic's own status history shows service-wide incidents and model-specific error spikes, each resolved within a bounded window but still real enough to interrupt a workflow mid-run.
A workflow that calls the model synchronously, with no fallback, inherits the provider's downtime as its own downtime. That is a design choice, not an unavoidable fact, and it is worth deciding on deliberately rather than by default.
- Check whether your provider publishes a status page and incident history.
- Note the typical duration and frequency of past incidents.
- Decide which workflow steps can tolerate waiting and which cannot.
A circuit breaker stops one failure from becoming many
The circuit breaker pattern wraps a remote call so that once failures cross a threshold, further calls fail fast instead of piling up behind a slow or unresponsive dependency. The breaker opens, requests stop reaching the provider, and after a cooldown it allows a trial call to check for recovery before closing again.
Without this, a struggling provider can produce the opposite of graceful degradation: a backlog of retries and timeouts that exhausts queue capacity, worker threads, or rate-limit budget right when the system most needs headroom to recover.
Decide the fallback before you need it
Three fallback behaviors cover most workflow steps: queue the work and retry once the provider recovers, degrade to a simpler rule-based response for low-stakes cases, or route the item to a person with the same evidence a reviewer would normally see. Which one applies depends on how time-sensitive and reversible the step is.
Write this decision down per step, not once for the whole workflow. A customer-facing draft can usually wait a few minutes; a time-boxed approval or an alert that feeds an on-call process usually cannot.
Reliability is a practiced path, not a document
AWS's reliability guidance frames this well: resilient systems come from anticipating failure, testing recovery, and managing change deliberately, not from assuming the happy path will hold. The same applies to a workflow built on a model API.
Run a scheduled drill where the provider call is forced to fail and confirm the breaker trips, the fallback activates, and the right person or queue receives the work. An outage is the wrong time to discover that the fallback path was never wired up.