Serverless Cold Start Latency — Swimlane & Latency Histogram

Traffic & Scaling

Request rate 6.0 req/s

Cold start latency 900 ms

Idle timeout (scale-down) 15 s

Concurrency / instance 4

Live Metrics

Active instances

0 / 24

Cold-start rate

p50 latency

0 ms

p95 latency

0 ms

Requests served

Queued (backpressure)

How it works

Same warm-pool FaaS autoscaler model as the 3D grid version — an M/G/c-style queue where each instance serves up to c concurrent requests — but rendered as two genuinely 2D-native diagrams instead of a rendered pool of containers:

A swimlane timeline (top) — one horizontal row per instance, scrolling left as time advances. Each column is a snapshot of every instance's state at that instant, so a lane's color history over the strip is that instance's whole lifecycle: grey (off) → orange (cold-starting) → green (warm/idle) → blue (busy, brighter with more concurrent load).
A latency histogram (bottom) — every completed request's end-to-end latency is binned live, with p50/p95 drawn as vertical markers directly on the distribution, making the cold-start tax visible as a second hump to the right of the warm-dispatch cluster.

latency = T_cold · [instance was cold] + T_queue + T_exec
p50 / p95 computed over the last 200 completed requests

An idle instance with zero active requests for longer than the idle timeout is torn down (scaled to zero), which is why bursty traffic after a quiet period pays the cold-start tax again — the classic serverless latency/cost trade-off used by AWS Lambda, Azure Functions and Google Cloud Run.

Off (scaled to zero) Cold starting Warm / idle Busy (serving)