What Is Golden Signals?

The golden signals are four metrics, latency, traffic, errors, and saturation, that give a team the fastest possible read on whether a service is healthy or in trouble. The idea comes out of Google's site reliability engineering practice, where a small team monitoring a huge number of services needed a minimal set of numbers that would catch almost any real problem without requiring a dashboard for every metric a system could theoretically produce. Each signal answers a distinct question: how long are requests taking, how many requests are coming in, how many of them are failing, and how close is the system to running out of some finite resource.

The reason golden signals exist is that most production incidents show up in one of these four places well before a team would notice them anywhere else, and most monitoring setups before this framework became common were either too sparse to catch problems or so noisy with metrics that nobody could tell which ones actually mattered during an incident. A team paging on-call engineers for every CPU tick or every log line drowns the people who need to respond in noise, while a team with no structured signals at all gets blindsided by outages that a simple latency or error rate check would have caught hours earlier. Golden signals sit in the middle: few enough to actually watch, broad enough to catch almost everything that matters.

What distinguishes golden signals from an arbitrary list of metrics is that the four were chosen because they are largely independent of each other and together cover the ways a service actually fails. A system can have high traffic with normal latency and be fine. It can have normal traffic with rising latency and be in trouble. It can have low error rates but climbing saturation and be minutes from falling over. Because each signal captures a different failure mode, a team watching all four gets a far more complete picture than it would from any single metric alone, no matter how carefully that one metric was chosen.

By 2026, golden signals have become close to a default vocabulary in observability tooling, showing up as pre-built dashboard templates in most major monitoring platforms and as the starting point for on-call runbooks at companies that never worked at Google and never read the original material describing the concept. The growth of distributed systems, where a single user request might touch a dozen services before returning a response, has made a small, consistent set of signals per service more valuable than ever, because it gives engineers a common frame to reason about any service in the stack without needing to learn a bespoke monitoring setup for each one. The framework has also aged well as tracing and metrics tooling has matured, since modern observability platforms make it far cheaper than it used to be to break each signal down by endpoint, region, or customer segment without the instrumentation cost that once made this kind of granularity impractical for anyone but the largest engineering organizations.

This page covers what each of the four signals actually measures, why these four were chosen instead of a longer or shorter list, how they typically show up in real dashboards and alerting rules, where the framework fits well and where it needs supplementing, and how a team actually implements golden signals monitoring without turning it into another neglected dashboard. The durable idea underneath all of it is that a small number of well-chosen signals, watched consistently, catches more real problems than a large number of metrics nobody has time to look at, and understanding that trade-off lets a team build monitoring that people actually use during an incident instead of monitoring that only looks thorough in a slide deck.

• The four golden signals are latency, traffic, errors, and saturation, each answering a distinct question about service health.
• The framework originated in Google's SRE practice as a minimal signal set that still catches most real incidents.
• The four signals were chosen because they are largely independent and together cover the common ways systems fail.
• Golden signals work best as the first layer of monitoring, not the only layer, especially for complex or specialized systems.
• Implementing golden signals well means separating them by request type and by percentile, not collapsing them into one average number per service.

Latency measures how long it takes to serve a request, and the detail that matters most is that a single average number hides the problem. A service can have a perfectly reasonable average latency of 200 milliseconds while 5% of requests take four seconds, and those slow requests are usually the ones a real user actually notices and complains about. This is why golden signals monitoring is built around percentiles, typically the 50th, 95th, and 99th, rather than a mean, and why teams often split latency into successful request latency and failed request latency, since a fast error is a very different problem from a slow success.

Traffic measures the demand being placed on the system, typically requests per second for a web service, but the right unit changes depending on what the system does. A streaming service might measure concurrent connections, a queue-based system might measure messages processed per second, and a batch system might measure jobs started per hour. Traffic on its own rarely signals a problem, but it provides essential context for interpreting the other three signals, since a spike in errors during a traffic surge tells a very different story than the same error spike during a quiet period with no unusual load.

Errors measure the rate of requests that fail, and the harder part of this signal is defining what actually counts as a failure. An HTTP 500 is an obvious error, but a request that returns a 200 status code with the wrong data, or one that times out at the client after the server was still processing it, often does not show up in a naive error count even though it represents exactly the kind of failure a user actually experiences. Teams that only track server-side error codes and ignore client-perceived failures end up with an error signal that looks clean while real users are having a genuinely bad time with the product.

Saturation measures how close a system is to its capacity limit, whether that limit is CPU, memory, disk I/O, connection pool slots, or some other finite resource the service depends on. Saturation is the leading indicator among the four signals; a system often shows rising saturation well before it shows rising latency or errors, which makes it the signal most likely to give a team advance warning before a real incident actually starts. The tricky part is that saturation has to be measured against the resource that will actually run out first, and that resource is frequently not the obvious one like CPU, but something more specific like a connection pool or a thread limit that only becomes visible once someone has actually hit it in production. Teams that skip this step and default to a generic CPU or memory percentage often get blindsided by an outage caused by a resource they were not watching at all, since the bottleneck a system hits first is rarely the same across every service in a company's stack, even when those services share the same underlying infrastructure and the same deployment platform.

The original framing behind golden signals was explicitly about minimalism: given limited time and attention during an incident, which handful of metrics gives the highest return for the effort spent watching them. Adding more signals to the required set dilutes attention during exactly the moments when fast, accurate judgment matters most, which is why the number stayed at four rather than expanding into a longer standard checklist over time as the industry adopted the idea.

The four signals were also chosen because they map onto distinct, mostly independent failure modes rather than overlapping ways of describing the same underlying problem. A system can be slow without erroring, and it can error without being slow. A system can be saturated without either symptom showing up yet, which is exactly why saturation earns its own place in the list rather than being folded into a broader idea like latency. Because the four signals capture largely separate failure modes, checking all four gives a genuinely more complete picture than checking any one of them more closely ever could on its own.

Other frameworks exist alongside golden signals and serve related but distinct purposes; the RED method, focusing on rate, errors, and duration, and the USE method, focusing on utilization, saturation, and errors, both cover similar ground with a different emphasis, one leaning toward request-level service health and the other toward resource-level infrastructure health. None of these frameworks compete directly with error budgets, which are a separate mechanism for deciding when reliability work takes priority over new features rather than a set of metrics to watch in a dashboard. Golden signals tell a team what is happening right now; an error budget tells a team how much of its allowed unreliability has already been spent this month.

Keeping the list at four also makes the framework teachable across an entire engineering organization in a way a longer list never manages to be. A new engineer joining a team can learn to check latency, traffic, errors, and saturation for any unfamiliar service within a few minutes, and that consistency across dozens or hundreds of services is worth more in practice than a longer, more customized list that only the original service owner ever fully understands or remembers under pressure. This matters most during an actual incident, when the person paged may not be the person who built the service, and a shared, predictable structure is often the only reason that responder can form a useful hypothesis about what is wrong within the first few critical minutes rather than spending that time simply learning how the dashboard is laid out.

In practice, most teams build one dashboard per service with four panels, one per signal, arranged so an on-call engineer can glance at all four within a few seconds during a page. Latency is usually shown as a set of percentile lines over time rather than a single number, traffic as a request rate graph, errors as a rate or percentage rather than a raw count, and saturation as a gauge or percentage against the relevant resource limit, whichever one is closest to being exhausted for that particular service.

Alerting rules built on golden signals tend to combine two of the four rather than firing on any single signal in isolation, because a single-signal alert produces too many false positives to be useful in a real on-call rotation. A common pattern pages on high error rate combined with meaningful traffic volume, since a 50% error rate on two requests a minute is statistical noise, not an incident, while the same 50% error rate on two thousand requests a minute is a real and urgent problem. Similarly, latency alerts are usually scoped to the 95th or 99th percentile rather than the average, since the average can look completely fine while a meaningful share of real users are having a genuinely slow experience.

Saturation alerts function differently from the other three because they are meant to be predictive rather than reactive, firing before a problem actually occurs rather than after it starts. A well-tuned saturation alert gives a team enough lead time to add capacity or shed non-critical load before latency and errors actually start climbing, which is the entire reason saturation earns a dashboard panel of its own rather than being treated as a secondary infrastructure metric buried somewhere in an infrastructure team's separate tooling.

Most teams that implement this well also tag each signal by request type or endpoint rather than collapsing an entire service into one aggregate number. A checkout service handling both browsing traffic and payment traffic benefits enormously from separate latency and error tracking for each, since a spike in browsing latency and a spike in payment latency have very different business consequences and very different appropriate urgency levels, even though both technically live inside the same overall service. The same logic applies to splitting signals by customer segment or geographic region when traffic is uneven across either dimension, since an aggregate view can easily hide a serious problem affecting one region or one high-value customer segment behind healthy-looking averages from everywhere else.

Golden signals work exceptionally well for request-driven services: web applications, APIs, and anything where a client sends a request and expects a response within some reasonable time. The framework was built around exactly this shape of workload, and it maps onto that shape cleanly, which is why it has become close to a default starting point for observability at companies running this kind of architecture.

The framework fits less naturally onto batch systems, event-driven pipelines, and asynchronous workloads, where there is no single request-response cycle to measure latency against in the first place. A data pipeline that processes a batch once an hour needs different signals entirely, things like freshness (how far behind is the pipeline relative to real time), completeness (did all expected records make it through), and throughput per run, rather than a request latency metric that does not really apply to that shape of system at all.

Golden signals also do not capture business-level correctness on their own. A checkout service can show perfect latency, healthy traffic, a near-zero error rate, and comfortable saturation while still charging customers the wrong amount due to a logic bug that never triggers an HTTP error of any kind. Teams that rely on golden signals alone, without any business-level correctness monitoring layered on top, often discover serious problems through a customer support ticket rather than through their own monitoring, which somewhat defeats the purpose of having monitoring at all. Layering business metrics, such as successful orders per minute or revenue per hour, alongside the four technical signals closes this gap, and the two together catch a much wider range of problems than either would on its own.

The framework also does not replace domain-specific signals for specialized systems. A message queue benefits from tracking queue depth and consumer lag as first-class signals in their own right, not just as a component folded into a generic saturation number. A machine learning inference service benefits from tracking prediction confidence distributions and model drift alongside the four golden signals, not instead of them. Golden signals should be understood as the floor every service needs, not the ceiling of what a well-monitored, mature service actually tracks in production. A database has its own natural extension of the framework too, with replication lag and lock contention often mattering as much as the original four signals, and a well-run platform team usually maintains a short list of these domain extensions per system category so nobody has to rediscover them from scratch each time a new service of that type gets built.

Start by instrumenting request-level latency and error tracking at the point closest to the actual user, ideally at a load balancer or API gateway rather than deep inside internal service code, since that vantage point captures what a real user experiences rather than what an individual internal service believes is happening to it. This single step usually surfaces the most actionable signal fastest, because it reflects the end-to-end experience rather than an isolated, disconnected piece of the larger system.

Add traffic and saturation instrumentation next, and be deliberate about identifying the actual limiting resource for each service rather than defaulting to a generic CPU or memory percentage that may not reflect the resource that will genuinely run out first. A service might be CPU-bound, memory-bound, connection-pool-bound, or bound by a downstream dependency's own rate limit, and the correct saturation metric depends entirely on which of these actually constrains that specific service under real load conditions. Load testing a new service before it reaches production is usually the fastest way to find this out, since it reveals which resource actually gets exhausted first under realistic pressure rather than leaving that discovery to whichever incident happens to surface it later.

Build alerts on combinations of signals rather than single thresholds from the very start, since single-signal alerting is the most common reason golden signals monitoring gets abandoned or muted within its first few months of operation. A team that gets paged constantly for low-traffic error blips stops trusting its alerts within a matter of weeks, and once an alert is muted or ignored by habit, it is effectively dead regardless of how correctly it was originally configured to fire.

Roll the four signals out consistently across every service using the same dashboard template and the same naming conventions, rather than letting each team build its own bespoke version with its own naming and its own layout. This consistency is what actually makes the framework valuable at scale: an engineer who has never seen a particular service before can still form a reasonably accurate opinion about its health within a couple of minutes, because the shape of the dashboard is already familiar from every other service they have worked with across the organization. Finally, treat the initial rollout as a starting point rather than a finished product; revisit which endpoint groupings, percentiles, and saturation resources actually mattered during the first few real incidents, and adjust the templates based on that evidence rather than leaving the original guesses in place indefinitely just because nobody got around to revisiting them.

• Track latency by percentile, not by average, since the average hides exactly the slow requests users actually notice and complain about.
• Separate error tracking by whether the response was client-perceived as a failure, not just by server-side status code.
• Identify the actual limiting resource per service before building a saturation metric, rather than defaulting to a generic CPU number.
• Build alerts that combine signals, such as error rate plus traffic volume, to reduce false positives during an on-call rotation.
• Apply the same dashboard structure across every service so engineers can reason about unfamiliar systems quickly during an incident.

• Golden signals are not a replacement for business-level correctness monitoring; a service can look perfectly healthy on all four while still producing wrong results.
• The four signals are not interchangeable with the RED or USE methods; they overlap in intent but are not identical frameworks with identical scope.
• Average latency is not an acceptable substitute for percentile latency; the two numbers routinely tell very different stories about the same system.
• Golden signals are not only relevant to companies operating at Google's scale; the framework applies just as usefully to a five-person team running one service.
• Saturation is not the same thing as CPU usage; the correct saturation metric depends on whichever resource actually constrains that specific service first.