What are the Four Golden Signals?

WHAT THIS TESTS This question verifies you know the small, high-value set of signals Google recommends for user-facing monitoring, and that you can translate one into a concrete measurement rather than reciting a list.

A GOOD ANSWER COVERS Name all four. Latency is the time to serve a request. Traffic is the demand on the system, often requests per second or transactions per second. Errors is the rate of failed requests, including explicit failures, wrong content, and policy violations like too slow. Saturation is how full the service is relative to its constraining resource, a forward-looking signal of impending trouble. Explain that these focus on user experience and impending capacity limits rather than raw internals. Then implement one, typically latency: instrument the endpoint to record per-request duration into a histogram, then compute percentiles such as p50, p95, and p99 over a window, rather than an average. Critically, separate the latency of successful responses from failed ones, because fast errors can otherwise make latency look great while users suffer.

COMMON WRONG ANSWERS Listing CPU, memory, disk, and network as the golden signals, those are resource metrics, not the four signals. Measuring latency only as an average, which hides tail behavior. Forgetting saturation, the most often-omitted signal. Mixing success and error latency together.

LIKELY FOLLOW-UPS Why measure percentiles instead of averages? Why split success and error latency? What is a good saturation proxy? How do these map to SLIs?

ONE CONCRETE EXAMPLE For an API endpoint, middleware times each request and emits the duration to a Prometheus histogram labeled by status. A dashboard then shows p50, p95, and p99 latency for successful responses, while error rate comes from the same labeled counter. Traffic is the request counter's rate, and saturation might be the in-flight request count versus the worker pool size, giving all four signals from lightweight instrumentation at one endpoint.