Skip to main content
fal is designed for production workloads and includes several built-in mechanisms to ensure your requests succeed. The platform applies three layers of protection automatically: a queue that absorbs traffic spikes, retries that recover from transient failures, and model fallbacks that reroute around unhealthy endpoints. All three are enabled by default and require no configuration.

​
Queue-Based Processing

The queue system handles traffic surges gracefully and provides request tracking. When you submit a request, it enters a managed queue that ensures reliable processing even during peak demand.

​
Automatic Retries

When using the queue, fal automatically retries requests that fail due to:
  • Server errors (503): The model endpoint was temporarily unavailable
  • Timeouts (504): The request took too long due to transient issues
  • Connection errors: Network issues between fal infrastructure
  • Rate limits (429): Request waits and retries automatically when you temporarily exceed your concurrent request limit
Requests are retried up to 10 times with intelligent backoff.
Limit retry duration: Use start timeout to cap the total time a request can spend waiting (including retries). Once the timeout is reached, no further retries occur.
No charge for server errors: Failed requests that return 5xx status codes are not billed.
Automatic retries only apply to queue-based requests. Direct synchronous requests return errors immediately without retry.
For per-request control over retries and timeouts, see the Queue page — including disabling retries with the X-Fal-No-Retry header, setting a start timeout with X-Fal-Request-Timeout, and using client timeout to set a client-side deadline.

​
Backup Domains

Backup domains provide an alternative connection to the same inference API when a primary domain is unreachable. Use the same API key, request path, query parameters, and body with the backup domain. If your network restricts outbound connections, allow HTTPS access to both primary and backup domains.

​
Python Client

The Python fal-client tries the corresponding backup once if the primary connection fails or times out. This applies to run(), submit(), subscribe(), queue operations, and stream(), including their async counterparts. No configuration is required.

​
Raw HTTP Requests

For direct HTTP calls, replace the hostname when connection establishment fails. For example:
If the primary remains unreachable, replace the hostname in returned queue status, result, and cancellation URLs.

​
Coverage

Python client fallback covers HTTP inference requests only. It does not cover WebSocket or realtime connections, or the separate fal.apps client. Token requests to rest.fal.ai and uploads to v3.fal.media do not have backup domains.

​
Model Fallbacks

For supported models, fal might automatically reroute requests to equivalent alternative endpoints if the primary endpoint is temporarily unavailable. This only occurs after fal retries the request up to five times; if those retries fail, the request is routed to a fallback endpoint. This mechanism improves overall reliability and reduces the likelihood of failed requests. Fallbacks are enabled by default for all accounts. If you need to disable fallbacks for your account, please let your account team know. If you want to disable it per request, you can pass the x-app-fal-disable-fallback header. For any questions, contact our sales team.