The Four Golden Signals of Monitoring

By Kokil Thapa | Last reviewed: September 2026

Production breaks in predictable ways. Requests slow down before they fail. Queues fill before disks do. The Four Golden Signals of Monitoring cut through metric noise and tell you whether users are actually suffering. Google introduced this framework in the Site Reliability Engineering book, and it still fits Laravel APIs, WooCommerce stores, and bare Ubuntu servers in 2026. If you run a support and maintenance contract or self-host on Linux, these four numbers belong on every dashboard.

What Are The Four Golden Signals of Monitoring?

The framework comes from Google SRE practice. It answers one question: is the service healthy for real users right now? You do not need hundreds of charts. You need four signal types that map directly to user experience.

• Latency — time to complete work, including queue wait inside the service.
• Traffic — demand level: requests per second, orders per minute, active sessions.
• Errors — failed work: HTTP 5xx, payment callback rejections, job retries exhausted.
• Saturation — how full the bottleneck resource is: CPU, memory, DB connections, queue depth.

Latency and errors tell you users are hurting. Traffic gives context—a spike explains higher latency. Saturation often predicts the next outage. Together they form a minimal observability contract. This pairs cleanly with the broader split between logs, metrics, and traces described in our guide on observability vs monitoring.

On a booking platform like Adventure Third Pole Trek, latency covers checkout and Livewire updates. Traffic tracks concurrent trek searches during peak season. Errors catch failed Khalti callbacks. Saturation watches MySQL connection pool and Redis queue depth.

How Do You Measure Latency as a Golden Signal?

Latency is not average response time alone. Averages hide slow tail requests that ruin checkout. Measure latency at the service boundary—the edge your users hit.

Use percentiles, not means

Track p50, p95, and p99 for HTTP handlers and API endpoints. A p99 of 2 seconds with a p50 of 120 ms means 1% of users wait painfully long. That 1% often includes payment flows.

# Prometheus histogram example (nginx or app middleware)
http_request_duration_seconds_bucket{le="0.1"} 8420
http_request_duration_seconds_bucket{le="0.5"} 9910
http_request_duration_seconds_bucket{le="1.0"} 9985
http_request_duration_seconds_bucket{le="+Inf"} 10000
http_request_duration_seconds_sum 892.4
http_request_duration_seconds_count 10000

In Grafana, graph histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])). Set alerts on p99 crossing SLO thresholds, not on CPU alone. Our Prometheus metrics fundamentals article walks through histogram setup in more depth.

Separate success latency from error latency

Failed requests often return fast—a 401 in 5 ms skews your latency chart downward. Filter by status code or result label:

histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket{status=~"2.."}[5m])) by (le, route)
)

For background jobs, latency means queue wait plus processing time. A Laravel job that waits 10 minutes then runs in 2 seconds still feels broken to the user waiting on email.

How Do You Track Traffic, Errors, and Saturation Together?

Traffic without latency context misleads. A traffic drop might mean DNS failure, not happy users leaving. Errors without traffic context hides rare but critical paths. Saturation without traffic misses idle resources that still matter at peak.

Traffic: quantify demand

Use counters that match business meaning:

• HTTP: rate(http_requests_total[5m]) by route and method.
• API: requests per consumer, per endpoint, with auth label stripped of secrets.
• Queues: enqueue rate vs dequeue rate on Laravel Horizon or Redis.
• eCommerce: orders per minute, cart submissions, payment attempts.

Compare today vs same hour last week. Dashain and Tihar spikes on Nepal-facing sites can double traffic without code changes. Plan capacity from that pattern.

Errors: count what users cannot complete

HTTP 5xx is the obvious error signal. Also track:

1. 4xx on critical paths (checkout 422 vs blog 404).
2. Payment gateway timeouts and webhook signature failures.
3. Queue job failures after max retries.
4. Health check failures on Laravel health endpoints.

# Error rate as golden signal
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Alert on error rate above 1% for five minutes, not on single 500s. One bad deploy can spike briefly; sustained rate means rollback.

Saturation: watch the bottleneck

Saturation asks how much headroom remains on the limiting resource. CPU at 40% can still mean saturation if the DB connection pool is maxed.

I've seen Laravel apps where Redis memory hit 100% while CPU looked fine. Sessions and cache evictions caused random logouts. That is saturation doing its job as an early warning.

Which Monitoring Tools Implement the Four Golden Signals?

You can implement golden signals on almost any stack. Pick tools your team will actually run at 2 a.m.

Prometheus and Grafana

Prometheus is the default choice for custom apps. Exporters cover MySQL, Redis, Nginx, and PHP-FPM. Grafana dashboards group the four signals per service. See our full Prometheus and Grafana stack guide for install steps on Ubuntu 22/24.

Netdata and Nagios

Netdata gives fast saturation views with minimal config—good on single-server Laravel hosts. Nagios suits check-based alerting on disk, HTTP, and queue depth. Neither replaces application-level error rates; add app metrics either way.

Cloud and APM options

Managed APM (Datadog, New Relic, Honeycomb) maps golden signals out of the box. Cost runs Rs 15,000–50,000/month (~USD 110–370) for small fleets. Self-hosted Prometheus on a Rs 3,000/month VPS (~USD 22) works when you accept setup time. For Linux system administration clients, I often start with Netdata plus one Prometheus job for the Laravel app.

Whatever you choose, store dashboards next to runbooks. A chart without "what to do next" wastes the alert.

How Do You Apply Golden Signals to Laravel and API Applications?

Framework apps need instrumentation at middleware and job boundaries. Server metrics alone miss logic errors and N+1 query latency.

Laravel: middleware and Horizon

Add request timing middleware that records histogram metrics or logs structured timing:

public function handle(Request $request, Closure $next)
{
    $start = microtime(true);
    $response = $next($request);
    $duration = microtime(true) - $start;

    Metrics::observe('http_request_duration_seconds', $duration, [
        'route' => $request->route()?->getName() ?? 'unknown',
        'status' => $response->getStatusCode(),
    ]);

    return $response;
}

For queues, export Horizon metrics: jobs per minute, failed jobs, wait time. Saturation shows up as queue:work processes at 100% CPU with growing Redis list length.

On production Laravel 12 or 13 apps, pair this with complete Prometheus setup and health routes that return JSON for synthetic checks.

REST APIs: per-consumer SLOs

API traffic should break down by client ID or API key hash. One partner sending bulk sync can spike latency for everyone else. Rate limiting—covered in our API rate limiting guide—protects saturation.

Error golden signals for APIs include:

• HTTP 5xx rate by endpoint version (/api/v1 vs /api/v2).
• Timeout rate on outbound payment or SMS calls.
• Webhook delivery failures and retry exhaustion.

Our API monitoring with Prometheus post shows scrape configs for Laravel Sanctum-protected metrics endpoints.

WordPress and WooCommerce

WooCommerce 11.1 on WordPress 7.1 needs different labels. Traffic means add-to-cart and checkout attempts. Latency covers TTFB on shop pages and admin-ajax calls. Errors include failed Stripe or eSewa redirects. Saturation hits PHP-FPM pm.max_children during flash sales—common on florist stores like Petals Qatar.

Alert rules that actually page you

Combine signals to reduce noise:

1. User impact: p99 latency > 2s AND error rate > 0.5% for 5 minutes.
2. Capacity: saturation > 85% AND traffic within 20% of weekly peak.
3. Queue backlog: oldest job age > 10 minutes AND traffic above baseline.

Send saturation-only alerts to Slack. Page on-call only when errors or latency confirm user pain. Tune with testing and optimization load tests before festival traffic.

Validate JSON health responses during deploys with a JSON formatter in your runbook—misformatted probes look like outages.

Key Takeaways

• The Four Golden Signals of Monitoring are latency, traffic, errors, and saturation—measure all four, not just CPU.
• Use p95 and p99 latency on success paths; averages hide checkout pain.
• Alert on error rates and sustained latency, not single failed requests.
• Watch saturation on the real bottleneck: DB pool, queue depth, or PHP-FPM workers.
• Instrument Laravel and APIs at middleware and job boundaries, not only the server.
• Correlate signals before paging—traffic spikes explain latency; saturation predicts tomorrow's outage.

People Also Ask

What is the difference between golden signals and RED/USE methods?

RED (Rate, Errors, Duration) applies to request-driven services—it maps directly to traffic, errors, and latency. USE (Utilisation, Saturation, Errors) applies to resources like CPU and disks. Golden signals cover both user-facing and resource views in one framework. Use RED for your API and USE for MySQL host metrics.

How many metrics do you need for golden signal monitoring?

Start with roughly 10–20 time series per service: one latency histogram, request counter by status, and four to six saturation gauges. Add labels for route, queue, or payment provider only where you will alert. Too many labels explode cardinality and slow Prometheus.

Can you use golden signals without Kubernetes?

Yes. The framework predates Kubernetes and works on a single Ubuntu VPS running Apache, PHP-FPM 8.4, and MySQL 8.4. Exporters and app middleware supply the same signals whether you have one server or forty.

When should you alert on saturation alone?

Alert on saturation alone when headroom is low during predictable peaks—disk above 90%, connection pool above 85%, or queue depth monotonically increasing. Otherwise pair saturation with latency or errors to avoid noise during off-peak idle states.

Build Dashboards That Match How Your App Actually Fails

The Four Golden Signals of Monitoring stay relevant because users care about wait time, broken flows, and unavailable pages—not obscure internal gauges. Start with one service, four panels, and three alert rules tied to real SLOs. Expand to APIs, workers, and payment paths once the baseline catches a real incident.

If you want golden-signal dashboards wired into your Laravel app, WooCommerce store, or enterprise application stack, I can help design metrics, alerts, and runbooks that fit your hosting budget. Read more on the Ubuntu server monitoring guide, browse the Notary Nepal portfolio for legal-tech uptime patterns, or contact us to review your current setup.