Skip to main content

​
Readiness & Liveness

​
At start

Fal considers an app as ready to serve requests immediately after the setup() method finishes successfully (see Core Concepts). If there is no setup() method, the app is considered ready as soon as the application web server is up. It is highly advisable to always use setup() to load necessary data and even perform a dummy evaluation to ensure that things work end to end. If setup() does not complete successfully or the web server port never opens, the runner is immediately terminated as unhealthy, and no requests forwarded to it.

​
Ongoing

Ongoing app readiness/liveness is determined based on the status codes it returns to requests:
  • 2XX status codes indicate a successful request (app is alive and ready)
  • 4XX status codes indicate a user error and are not retried (app is alive and ready)
  • 503 status code indicates the runner is not healthy. The request is retried (when using the queue) and the runner is immediately terminated.
  • 504 status code indicates that an upstream dependency is not healthy (but the app itself is). The request is retried, but the runner is not terminated.
  • Other 5XX status codes are not retried and the runner is not terminated
You can override this behavior on a per-response basis using the X-Fal-Needs-Retry response header (1 to force retry, 0 to prevent retry), regardless of the status code. See Override Retry Behavior Per Response for details. There are 2 additional states in case the app misbehaves:
  • The connection with the app breaks (e.g. the app crashes): requests that use the queue are retried, direct requests get a 503 status. The runner is shut down.
  • The app takes longer to respond than the request timeout: requests that use the queue are retried, direct requests get a 504 status. The runner is shut down as it may be faulty.

​
Health Check

You can add a health check endpoint to your application to ensure that your runners are healthy and ready to serve requests. If the health check fails for a few consecutive times, the runner is terminated and a new one is spun up. See health check endpoint docs for details.