The four golden signals are latency, traffic, errors, and saturation. The idea comes from Google's Site Reliability Engineering book, which suggests that if you can measure only four things about a user-facing system, these give the broadest view of its health.
Why it matters
Teams often drown in hundreds of graphs and still miss the obvious. Golden signals give a consistent starting point for every service and a quick triage order during an incident. They also map neatly onto alerts that matter to users.
Example
For a web API, the four signals could be:
- Latency: 95th and 99th percentile response time, tracked separately for successful and failed requests, since fast errors can hide slow successes.
- Traffic: requests per second.
- Errors: share of responses with 5xx status, plus wrong answers returned with a 200.
- Saturation: CPU, memory, queue depth, connection pool use.
A page might fire when the 5xx ratio exceeds 2 percent for five minutes, or when p99 latency doubles against a weekly baseline.
Common mistakes
- Averaging latency, which hides the slowest users. Use percentiles.
- Counting only HTTP 5xx and missing errors that return 200 with an error body.
- Treating the four signals as a full observability strategy. They tell you that something is wrong, not why.
- Confusing them with the RED method (rate, errors, duration) and USE method (utilization, saturation, errors), which are related but have different scopes.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.