SRE Golden Signals: Complete Guide to the Four Key Metrics (June 2026)

The Google SRE golden signals tutorial in the SRE book puts it plainly: if you can only measure four metrics of your user-facing system, focus on latency, traffic, errors, and saturation. That framing matters because the golden signals of SRE aren't a monitoring checklist, they're a prioritization framework built for teams buried under hundreds of dashboards who need to know which four numbers actually tell them whether their service is healthy. We're covering how each of the SRE practices golden signals captures a distinct dimension of system behavior, why golden signals saturation predicts capacity problems before they hit, and how connecting the 4 golden signals Google SRE framework to your actual incident workflow means you stop measuring everything and start measuring what reflects user experience.

TLDR:

• Google's SRE book defines four golden signals: latency, traffic, errors, and saturation.

• Track latency for successful and failed requests separately to avoid misleading metrics.

• Traffic gives the other three signals context; a latency spike at 10x load tells a different story than at 3 AM.

• Saturation predicts resource exhaustion before it happens; most teams alert at 80% and panic at 95%.

• Autoheal queries logs, metrics, and traces against the PCG to surface root cause hypotheses and preventive fixes when golden signal thresholds breach.

What Are the SRE Golden Signals

The four golden signals come from Google's Site Reliability Engineering book, which puts it plainly: if you can only measure four metrics of your user-facing system, focus on latency, traffic, errors, and saturation.

That framing matters. The golden signals aren't a monitoring checklist. They're a prioritization framework, built for teams buried under hundreds of dashboards and thousands of time series, who need to know which four numbers actually tell them whether their service is healthy right now. Each signal captures a distinct dimension of system behavior, and together they give you a surprisingly complete picture of user-facing reliability without requiring you to instrument everything at once.

Latency: Measuring Request Response Time

Latency tracks how long your service takes to respond to a request. The obvious reason it matters: slow responses degrade user experience before anything actually breaks. But the less obvious reason is where most teams get tripped up.

You need to measure latency for successful and failed requests separately. An HTTP 500 triggered by a lost database connection might return in 3 milliseconds, far faster than a healthy response. If you lump those fast errors into your overall latency distribution, the numbers look artificially good. Your p50 drops, your dashboards stay green, and meanwhile users are getting error pages. Filtering errors out entirely isn't the fix either, because slow errors, like a request that hangs for 30 seconds before timing out, tell you something different about system behavior than fast ones do. Track both, but track them apart.

Traffic: Understanding System Demand

Traffic measures how much demand your system is handling right now, usually expressed as requests per second, transactions per minute, or whatever unit fits your service. A video streaming backend might track concurrent streams; a payment gateway counts transactions.

What makes traffic worth watching on its own is that it gives the other three signals meaning. A p99 latency spike during 10x normal traffic tells a different story than the same spike at 3 AM with barely any load. A sudden drop in traffic, with no corresponding error spike, often points to an upstream failure or a routing change that's silently sending requests somewhere else, making early detection critical to reduce alert fatigue. You'll catch that faster than waiting for users to report it.

Traffic patterns also expose runtime rhythms: when your peak hours actually fall, which days carry the heaviest load, and where maintenance windows can safely land. Anomalies in traffic shape, like a sharp, continuous surge that doesn't match any known usage pattern, can flag retry storms or DDoS attempts before saturation metrics even flinch.

Errors: Tracking Failed Requests

Errors measure the rate of requests that fail, but "fail" isn't as simple as it sounds. Explicit failures like HTTP 5xx responses are easy to catch. Implicit failures, where a request returns 200 OK but serves the wrong content or stale data, are harder. Policy failures, such as requests rejected by rate limiting, sit in a gray area: technically correct behavior, but still a degraded experience for the user on the other end.

Even a small uptick in error rate can erode user trust faster than a latency spike, partly because some errors stay hidden until you connect them with user behavior or downstream service complaints. That's why experienced SRE teams track error ratios and error budgets instead of raw counts. A ratio tells you what percentage of traffic is failing right now; an error budget tells you how much failure you can tolerate before reliability commitments are at risk, giving you room to ship features without blowing past your thresholds.

Saturation: Monitoring Resource Utilization

Saturation measures how close your system is to its capacity limits, and it's the trickiest of the four signals to get right. CPU, memory, disk, network bandwidth, file descriptors, database connections: any of these can become the bottleneck, and the one that matters most changes depending on your workload.

What makes saturation distinct is its predictive value. The Google SRE book calls out that saturation is concerned with predictions of impending exhaustion, like noticing your database will fill its hard drive in four hours. Watching your 99th percentile response time over a short window can give you an early saturation signal before any resource actually hits the wall. Most teams set alerts at 80% utilization as a warning and 95% as critical, because by the time you reach 100%, recovery options narrow fast.

The practical challenge is knowing which resource to watch. You want to identify and instrument your bottleneck resource for each service, not blanket every metric with the same thresholds.

Why Golden Signals Matter for SRE Teams

The golden signals reframe what you're actually asking when you look at a dashboard. Instead of "are my servers running properly?" the question becomes "is my service working well for users?" That distinction matters because teams that monitor infrastructure health alone tend to measure what's easy to instrument, not what reflects user experience.

By anchoring alerts to service-boundary metrics, you cut through infrastructure noise and reduce false pages. Four signals, tracked consistently across services, give every team a shared vocabulary for health, which compresses both Mean Time to Detect (MTTD) and Mean Time to Resolve (MTTR) because the on-call engineer isn't hunting through unrelated dashboards to figure out where degradation started, a problem self-triaging agents solve.

How to Implement Golden Signals Monitoring

Start with one service. Pick the one that pages you most, map its boundaries, and build a single dashboard showing all four signals on one screen with no scrolling. If any engineer can't assess that service's health in 10 seconds, the dashboard needs work.

From there, the steps are straightforward: instrument your code to export latency histograms, request counters, error rates, and resource utilization metrics. Set baselines from two weeks of normal traffic, then tie alert thresholds to your Service Level Objectives (SLOs) so pages fire on user impact, not arbitrary numbers. Review historical data monthly for capacity planning.

The harder part is organizational. Golden signals monitoring only sticks when every team agrees on what "healthy" means for their services. That's a conversation, not a config file.

Golden Signals vs RED Method vs USE Method

All three frameworks pull from the same underlying telemetry, but they slice it differently. The RED Method (Rate, Errors, Duration) targets microservice request flows and skips resource-level concerns entirely. The USE Method (Utilization, Saturation, Errors) focuses on infrastructure components and has no equivalent to latency or traffic. Golden Signals cover both dimensions, which is why Google's SRE book frames them as the default starting point.

Pick based on what you're monitoring. RED works well for individual microservices where you care about request behavior. USE suits hardware or VM-level capacity work. Golden Signals sit between the two, and for most user-facing services they're the right default because traffic gives the other metrics context that neither RED nor USE captures on its own.

Connecting Golden Signals to SLIs and SLOs

Golden signals become actionable when you tie them to SLIs and Service Level Objectives. Your p99 latency is an SLI; the target you set for it ("99% of requests under 200ms") is the SLO. Error rate maps directly to availability. Saturation feeds capacity planning so you can keep those commitments under growing load.

Each signal's contribution to SLO compliance flows into error budget math. When latency breaches its SLI threshold or error rate climbs, your error budget burns faster, and that burn rate tells you whether to freeze deployments or keep shipping. Traffic volume closes the loop: the same error count means very different things at 100 requests per second versus 10,000.

Tools for Monitoring Golden Signals

Prometheus paired with Grafana remains the most common open-source stack for golden signals work. Prometheus handles metric collection and alerting rules; Grafana provides the visualization layer where you build those single-screen dashboards. For commercial options, Datadog and New Relic offer built-in golden signals dashboards with log correlation and distributed tracing baked in.

The tool matters less than what it surfaces. Collecting the four metrics is table stakes, which is why choosing the right SRE tool categories matters. What separates a useful setup from a noisy one is whether your tooling links a latency spike with a specific deployment, ties an error surge to a saturated connection pool, and trends historical data for capacity decisions, all without forcing you to pivot across five tabs during a live incident.

Best Practices for Golden Signals Implementation

The practices that survive in production share a common trait: they reduce decisions during incidents, not add them.

Instrument at the RPC client library level instead of inside each service individually. A single instrumentation point at the shared client gives you consistent latency, error, and traffic metrics across every dependency without asking each team to implement their own counters. One library change propagates everywhere.

Keep alert rules simple and predictable. A rule that fires when error rate exceeds 1% for five minutes is easy to reason about at 3 AM. A rule with four nested conditions and changing thresholds isn't. Every added condition is a potential source of confusion during triage.

Tie golden signals to business metrics like conversion rate, checkout completion, or revenue per minute, the kind of work AI SRE capabilities can automate. When an SRE can show that a latency regression from 150ms to 400ms matched a 12% drop in conversions, reliability stops being an engineering concern and becomes a business one. That shared understanding is what keeps monitoring investment funded past the first quarter.

How Autoheal Accelerates Golden Signals Monitoring for SRE Teams

When golden signal thresholds breach, Autoheal's agents query logs, metrics, traces, deploy history, and code changes against the Production Context Graph (PCG) to produce ranked root cause hypotheses with full decision traces before your on-call engineer opens a terminal, providing the evidence needed to write incident reports. For saturation signals flagging impending capacity constraints, the Analyzer agent queries the PCG to surface preventive fixes: missing observability config, infrastructure scaling recommendations, and alert tuning proposals.

Autoheal captures SLA-relevant data at resolution time as a byproduct of normal incident response, making per-customer SLA dashboards tractable without spreadsheet reconciliation. And because Autoheal runs entirely inside your cloud account with Bring Your Own Cloud (BYOC) deployment, golden signal telemetry never leaves your VPC, which matters if your security and compliance teams need to sign off before any AI agent touches production data.

Final Thoughts on Implementing Golden Signals Across Your Services

The hardest part of golden signals monitoring is getting every team to agree on what healthy means for their service. Once you have that shared vocabulary, the metrics themselves are straightforward to instrument and the dashboards become the single source of truth during incidents. Book a demo to see how Autoheal turns golden signal breaches into investigation triggers that query your observability stack and produce decision traces before your engineer even acknowledges the page.

FAQ

What's the difference between Golden Signals, RED Method, and USE Method?

Golden Signals cover both service requests and resource capacity across latency, traffic, errors, and saturation. RED focuses only on microservice requests (Rate, Errors, Duration) and ignores resources, while USE targets infrastructure components (Utilization, Saturation, Errors) and skips request-level performance. Pick Golden Signals for user-facing services where you need both dimensions visible at once.

Can I track saturation without monitoring every resource?

Yes. Identify your bottleneck resource per service and instrument that first. Watch your p99 response time over a short window to catch saturation signals before any resource actually hits 100%. Most teams set alerts at 80% utilization as a warning and 95% as critical, because by the time a resource maxes out, recovery options narrow fast.

How do I implement the 4 golden signals of monitoring for microservices?

Start with one service. Build a single dashboard showing latency histograms, request counters, error rates, and resource utilization on one screen with no scrolling. Instrument at the RPC client library level so a single instrumentation point gives you consistent metrics across every dependency without asking each team to implement their own counters. Set alert thresholds tied to your Service Level Objectives so pages fire on user impact, not arbitrary numbers.

Why track latency for successful and failed requests separately?

An HTTP 500 triggered by a lost database connection might return in 3 milliseconds, far faster than a healthy response. If you lump those fast errors into your overall latency distribution, the numbers look artificially good while users get error pages. Track both successful and failed request latency separately, because slow errors tell you something different about system behavior than fast ones do.

How does Autoheal investigate golden signal breaches?

Autoheal's agents query logs, metrics, traces, deploy history, and code changes against the Production Context Graph when golden signal thresholds breach, producing ranked root cause hypotheses with full decision traces before your on-call engineer opens a terminal. For saturation signals flagging impending capacity constraints, the Analyzer agent surfaces preventive fixes including missing observability config, infrastructure scaling recommendations, and alert tuning proposals.