Self-hosted docs
Failover Patterns
Keep your SLA commitments when providers degrade by routing traffic to approved alternatives.
Fallback destination controls
Define allowlisted endpoints for each route so reroutes remain compliant with policy and security constraints.
- Example: Allowlist fallback endpoints in failover policy configuration
- Example: Fallback endpoints must pass same policy checks as primary
- Example: Security constraints applied consistently across all destinations
- Request: POST /v1/failover/policies {route_id: "prod-chat", fallback_endpoints: ["backup-chat-v1", "backup-chat-v2"]}
- Response: {policy_id: "fail-123", status: "active", approved_endpoints: ["backup-chat-v1", "backup-chat-v2"]}
- API Reference: See [Failover Policies](/docs/api#failover-policies) for full contract details
Provider degradation triggers
Use correlated runtime and status signals to trigger failover at the right moment, not too early or too late.
- Example: Correlated latency spikes and provider status changes trigger failover
- Example: Multiple degradation signals required for high-confidence triggers
- Example: Gradual rollback when primary provider recovers
- Request: POST /v1/failover/triggers {route_id: "prod-chat", signals: ["latency_spike", "provider_outage"], confidence: 0.95}
- Response: {trigger_id: "trig-456", action: "activate_failover", timestamp: "2024-03-15T14:40:00Z"}
- API Reference: See [Failover Triggers](/docs/api#failover-triggers) for full contract details