> ## Documentation Index
> Fetch the complete documentation index at: https://fal.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Runner Analytics
> Debug individual runners with cold start stage breakdowns, live telemetry, per-runner logs, and shell access.
The Runners page gives you infrastructure-level visibility into the machines serving your app. Where [App Analytics](/docs/documentation/serverless/observability/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](/docs/documentation/deployment/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`](/docs/api-reference/cli/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](/docs/documentation/serverless/observability/monitor-performance#cli) and the [`fal runners`](/docs/api-reference/cli/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](/docs/documentation/serverless/optimizations/optimize-cold-starts), [compiled caches](/docs/documentation/serverless/optimizations/optimize-startup-with-compiled-caches), [FlashPack](/docs/documentation/serverless/optimizations/flashpack), and scaling parameters like the concurrency buffer in [Scale Your Application](/docs/documentation/deployment/scale-your-application).
Runner lifecycle, states, and caching
Techniques to reduce startup latency
Request metrics, latency percentiles, and cold boot rate
Timeline, filtering, and sharing for runner and request logs