Golden signals

The four signals

Latency measures how long a service takes to handle a request. It is useful to separate successful responses from errors because a fast error is not a successful user experience. Traffic measures demand, such as requests per second, messages consumed, or jobs started.

Errors show how often requests fail. Depending on the system, that can include explicit server errors, invalid responses, timeouts, or business operations that did not complete. Saturation shows how close a resource is to its practical limit. CPU can be saturated, but so can connection pools, queues, memory, or a provider rate limit.

Use the signals together

No single signal explains every failure. A rise in latency during a traffic spike may indicate saturation. A drop in traffic may indicate a broken client or an outage upstream. An error rate can look stable while one important endpoint is failing, so the useful dimensions and aggregation boundaries matter.

Choose measurements that reflect the service's actual work. A background worker may need queue age and completion delay, while an API may need request latency and error ratio. Keep a view at the service level and drill into routes or dependencies when investigating.

From dashboard to action

Golden signals are a starting framework, not a fixed dashboard template. Pair them with service-level indicators, objectives, and runbooks that explain what a responder should do. When a signal changes, connect it to deployment and ownership history so the team can test plausible causes quickly. Good engineering analytics preserves that relationship between operational evidence and the work that changed the system.