Runner Analytics

The Runners page gives you infrastructure-level visibility into the machines serving your app. Where App Analytics tells you what your traffic and latency look like, Runner Analytics tells you why — which stage of startup is slow, how a runner is using its resources, and what it logged before it failed. It is the fastest way to go from “some requests have a long cold start” to the specific runner and stage responsible. For background on what runners are and their lifecycle states, see Understanding Runners.

​

Runner States and Cold Start Stages

The Runners page opens with a breakdown of your runners by state (running, pending, docker pull, draining, and more). Each runner row also exposes the individual stages that make up its cold start, so you can see exactly where startup time goes:

• Pending — time to allocate a runner from fal infrastructure. High pending time on scarce or bursting GPU types (for example, B200s) points to capacity pressure rather than your code.
• Docker pull — time to pull the container image. Rows indicate whether the image was cached or required a full pull.
• Setup — time spent in your setup() function, typically loading model weights onto the GPU. This is often the largest contributor to cold starts.
• Cold start — the total startup time across all stages.

You can sort runners by cold start time to immediately surface the slowest ones, then drill into any single runner for detail.

​

The Runner Side Sheet

Clicking a runner opens a side sheet with everything you need to debug it:

• Cold start timeline — a stage-by-stage visualization of the runner’s startup, making it obvious whether the delay came from allocation, docker pull, or your setup code.
• Telemetry — CPU, memory, GPU, and VRAM usage over time, so you can spot resource exhaustion (for example, an out-of-memory condition).
• Logs — the full log timeline filtered to that runner ID, from spin-up through request execution, so errors like CUDA out-of-memory are easy to find in context.
• Connect — SSH into an active runner with fal runners shell to inspect the live environment (for example, run nvidia-smi to check driver specs and VRAM in real time). Available for active runners only.
• Termination reason and error type — see why a runner was terminated (for example, a runner error) directly in the header.

​

Managing Runners

From the runner list or side sheet you can act on runners directly — use the actions menu to gracefully stop a runner (letting it finish its current request) or kill it immediately. See Monitor Runners and the fal runners reference for the equivalent CLI commands.

​

Reducing Cold Starts

If Runner Analytics shows consistently high pending or setup times, that is a signal to optimize. Reserved capacity eliminates pending and setup time for a guaranteed pool of GPUs, giving predictable performance and economics. For setup-time reductions, see Optimize Cold Starts, compiled caches, FlashPack, and scaling parameters like the concurrency buffer in Scale Your Application.