Rate Limits for Runner and App Management
By Steven Van ·
The limits cover CLI, Python SDK and REST management calls; requests to app endpoints are unaffected.
Calls that manage apps and runners on fal now have per-minute limits across the CLI, Python SDK and REST API. The limits protect the shared control plane and do not apply to requests that call app endpoints.
Limits by operation
Calls are counted separately for each client in a one-minute window. A CLI command and its corresponding Python SDK method share the same limit.
- Listing apps or runners: 120 calls per minute.
- Listing an app’s runners: 300 calls per minute.
- Runner logs: 120 calls per minute.
- Runner shell or exec: 90 calls per minute.
- Stopping runners: 60 calls per minute.
- Killing runners: 300 calls per minute.
The REST endpoints GET /runners and GET /runners/{runner_id} each allow 120 calls per minute. The CLI’s logs command fetches runner details once before showing logs, and that call counts toward the runner-detail endpoint’s limit.
Handling rejected calls
Exceeding a limit returns 429 Too Many Requests through REST, or RESOURCE_EXHAUSTED through the CLI and Python SDK. Both include an x-ratelimit-reset header giving the seconds until the window resets. For gRPC calls, it is available in trailing metadata.
The CLI and SDK do not retry automatically. Code must wait until the window resets and retry the rejected call. If a stop or kill call is rejected, the runner continues to run.
The rate-limit documentation recommends spacing out polling calls, fetching all runners for an app in one list call, and spreading large batches of stop or kill calls over time.
