Golden signals for capacity planning

WHAT THIS TESTS: Whether you know the canonical monitoring signals and can connect them to capacity and scaling decisions from the start.

A GOOD ANSWER COVERS: The four golden signals from Google's SRE practice. Latency, how long requests take, measured at percentiles such as p50, p95, and p99 rather than the average, and split between successful and failed requests so slow errors do not hide in the success numbers. Traffic, the demand on the system, typically requests per second or another throughput unit, which tells you how load is growing. Errors, the rate of requests that fail, explicitly or implicitly. Saturation, how full your most constrained resource is, whether CPU, memory, disk I/O, or connection pools, which is the leading indicator of when you must add capacity. Correlating saturation and latency against traffic lets you forecast the headroom you have and when to scale.

COMMON WRONG ANSWERS: Watching only CPU utilization, reporting only average latency, omitting error rate, or ignoring saturation of non-CPU resources like connection pools that often bottleneck first.

LIKELY FOLLOW-UPS: Why percentiles over averages? Which resource usually saturates first? How do you set alert thresholds on these? How do these signals feed an autoscaler?

ONE CONCRETE EXAMPLE: From day one your dashboard tracks p99 latency, requests per second, error rate, and connection-pool utilization. Over weeks you notice that as traffic climbs toward eight hundred requests per second, pool utilization hits eighty percent and p99 latency starts rising while CPU stays modest. That tells you the connection pool, not CPU, is the binding constraint, so your scaling plan focuses there. Without saturation and percentile data you would have wrongly concluded the service was fine because average latency and CPU looked healthy.