Documentation
Examples
SDK Reference
Platform API
ChangelogRequests
Navigate to Dashboard > Apps > [your-app] > Analytics to see request metrics. You can filter by endpoint, date range, and view mode (your requests vs all requests to your app). The key metrics to watch are request throughput, latency percentiles (P50, P90), and error rate. If latency is higher than expected, drill into individual requests to see a full breakdown from submission to completion, including inputs, outputs, and logs. If errors are spiking, use Error Analytics for a detailed breakdown by status code and error type.Runners
The runners view shows how your infrastructure is performing. Use it to understand whether your scaling parameters are tuned correctly. If runners are spending most of their time in setup, your cold starts are too long. Look at Optimizing Cold Starts for strategies. If runners are mostly idle, yourkeep_alive or min_concurrency may be too high. If the queue is consistently deep, you may need to increase max_concurrency or add concurrency buffer.
You can also inspect individual runners to see their CPU, memory, and VRAM usage, and jump directly to their logs for debugging.
Metrics Definitions
Request Timing
Every request passes through several stages. The dashboard breaks these into two key charts: Request Startup (time before processing begins) and Request Duration (time spent processing).| Metric | What it measures |
|---|---|
| Request Startup | Time from submission until the request starts processing on a runner. For queued requests, this includes queue wait time and runner acquisition. If a cold start is needed, the startup time includes waiting for the new runner’s setup() to complete. This is the metric most affected by scaling parameters. |
| Request Duration | Time the request spent processing once it reached a runner. This is the actual execution time of your endpoint handler. Does not include queue wait or cold start time. |
| Time to First Byte | Time from when the request was sent to the runner until the first byte of the response was received. Useful for streaming endpoints where you want to measure how quickly the user sees initial output. |
| Latency Percentiles (P50, P75, P90) | Both Request Startup and Request Duration are shown at the 50th, 75th, and 90th percentile. P90 means 90% of requests completed faster than this value. Use P90 to understand worst-case performance for most users. |
Runner Timing
Runner time is split into three categories. The dashboard shows these as a stacked area chart over time.| Metric | What it measures |
|---|---|
| Startup Time | Time spent in the SETUP state, running your setup() method. This is your cold start cost. Appears once per runner lifecycle, not per request. Reduce it with FlashPack, compiled caches, or by optimizing your setup() code. |
| Execution Time | Time the runner spent actively processing requests (in the RUNNING state). This is the productive time you want to maximize. |
| Idle Time | Time the runner was alive but not processing any requests (in the IDLE state). Several scaling parameters affect idle time. keep_alive controls how long a runner stays alive after its last request before being terminated. min_concurrency keeps runners permanently warm even with no traffic, which means they accumulate idle time continuously. concurrency_buffer maintains extra runners above current demand, so those buffer runners are idle until traffic increases. scaling_delay makes the autoscaler wait before spinning up new runners, which can reduce idle time by reusing existing runners instead of creating new ones that sit idle. |
| Runner Utilization | Execution time as a percentage of total runner time (startup + execution + idle). Higher utilization means your runners are spending more time doing useful work. If utilization is low, look at which idle-time factor is the largest contributor: reduce keep_alive if runners linger too long after traffic stops, reduce min_concurrency if you have more warm runners than you need, or increase scaling_delay to encourage runner reuse. |
Queue and Concurrency
| Metric | What it measures |
|---|---|
| Queue Size | Number of requests currently waiting in the queue for an available runner. A consistently growing queue means you need more runners (increase max_concurrency or concurrency_buffer). |
| Concurrent Requests | Number of requests being actively processed across all runners at a given moment. |
| Error Rate | Percentage of requests that returned a 4XX or 5XX status code over the selected time period. |