[ GLOSSARY ]

The four golden signals

QUICK ANSWER

What are the four golden signals and how do they apply to Laravel?

Latency, traffic, errors, and saturation — Google SRE's minimum monitoring set for user-facing services. For Laravel: latency = p95 per route, traffic = requests per minute, errors = 5xx rate and exception count, saturation = worker pool utilization, queue depth, DB connection usage. Every user-facing endpoint should expose all four. NightOwl surfaces latency and traffic on the requests dashboard, errors on exceptions, and saturation via queue and worker health views.

Updated · 2026-04-13

Where they come from

Google's Site Reliability Engineering book (2016, freely available online) introduced the four golden signals as the minimum set of service-level signals worth monitoring. They're the prioritization answer to "if you can only monitor four things, monitor these."

Signal 1 — Latency

How long requests take. Measured in percentiles, not averages. Track p50, p95, p99 per route. Alert on sustained p95 elevation against a rolling baseline.

Laravel: the Nightwatch package records per-request duration. NightOwl groups by route pattern and computes percentiles automatically.

Signal 2 — Traffic

How much demand your service is receiving. Usually requests per second or per minute. Useful two ways: spot unusual load (attack, viral moment, Monday morning traffic) and sanity-check other signals (a latency spike during 10x traffic is different from one at normal load).

Laravel: requests per minute per route. Include 2xx, 3xx, and 4xx — every request counts as traffic.

Signal 3 — Errors

Rate of failed requests. Usually expressed as a percentage of total traffic. Also includes errors that return 200 but failed business logic (a checkout that returned 200 with an "inventory unavailable" message).

Laravel: 5xx response rate per route, unhandled exceptions per minute, grouped by fingerprint. Pair with report() for expected-exception tracking.

Signal 4 — Saturation

How full any bounded resource is. The leading indicator — saturation climbs before latency spikes or errors jump. Most important and hardest to measure.

Laravel-specific saturation surfaces:

  • PHP-FPM pool — what % of pm.max_children are busy. Query via pm.status_path.
  • Queue depth — pending jobs per queue. Rising depth = consumer lag.
  • Queue latency — dispatch-to-start time. See our queue latency guide.
  • DB connection pool — max_connections usage in Postgres's pg_stat_activity.
  • Redis memory — used_memory as a % of maxmemory.
  • Disk — log volumes, session storage, uploaded file storage.

Putting them together

Signal Laravel metric Alert style
Latencyp95 per routeSustained threshold breach
Trafficreq/min per routeAnomaly detection both ways
Errors5xx rate, new exceptionsImmediate on new groups
SaturationPool %, queue depth, DB connsHeadroom threshold (e.g. 90%)

RELATED

Frequently asked questions

What are the four golden signals?

Latency, traffic, errors, and saturation — four metrics Google's SRE book (2016) recommends monitoring for every user-facing service. If you only get to monitor four things, monitor these. Latency: how long requests take. Traffic: how many requests per second. Errors: rate of failed requests. Saturation: how full the system is.

How do I apply the four golden signals to Laravel?

Per-route: latency (p95 response time), traffic (requests per minute), errors (5xx rate), saturation (queue depth, worker utilization, DB connection pool usage). A Laravel-aware APM computes all four automatically. NightOwl surfaces latency and traffic on the requests dashboard, errors on the exceptions dashboard, and saturation via queue lag and worker health.

What does 'saturation' mean for a Laravel app?

How full any bounded resource is. For Laravel: PHP-FPM worker pool utilization (what % of pm.max_children are busy), queue depth and lag, DB connection pool usage, Redis memory, disk space on log volumes. Saturation is the leading indicator — it climbs before latency spikes or errors jump.

How are golden signals different from the USE method?

Google's golden signals target services from the outside (what users experience). Brendan Gregg's USE method (Utilization, Saturation, Errors) targets resources from the inside (what servers are doing). Both complement each other — golden signals for service-level SLOs, USE for infrastructure root cause.

Should I alert on all four golden signals?

Yes, but with different strategies. Alert on errors immediately (5xx rate spike). Alert on latency with sustain (p95 elevated for 5+ minutes). Alert on traffic anomalies both ways (drops suggest outage upstream; spikes suggest attack or viral moment). Alert on saturation with headroom (worker pool at 90%, DB connections at 95%) before things break.

Are the four golden signals enough?

For user-facing web services, yes — at service level. You'll layer additional signals for specific business needs (payment success rate, search relevance). For infrastructure (DB, cache, queues) layer USE-method signals. Golden signals are the minimum viable set for each service, not the complete monitoring portfolio.

PRICING

Flat pricing. No event caps. No per-seat fees.

14-day free trial, no credit card. Your PostgreSQL, your data.

HOBBY

$5 /month

1 app · 14 days lookback · all Laravel events

TEAM

$15 /month

Up to 3 connected apps · unlimited environments · all Laravel events

AGENCY

$69 /month

Unlimited apps · unlimited agent instances · same flat rate at any traffic

Start 14-day free trial See full pricing