---
name: Monitoring
description: Observe what matters before users tell you.
---
# Monitoring

Monitoring tells you the system is broken before customers do. The signal you want is "we knew and were already fixing it" — never "the user reported it".

## Three signals
- **Metrics.** Numeric time-series (request rate, error rate, latency, saturation). The dashboard view.
- **Logs.** Discrete events with context. The forensics view — why a specific request failed.
- **Traces.** A request's path across services. The localization view — where in the system the time went.

## Alerts
- **Alert on symptoms, not causes.** "Error rate up" is actionable at 3am; "CPU at 80%" might be fine or might be the cause — make the alert on what the user feels.
- **Every alert is actionable.** If nobody can do anything about it, it's noise. Noise trains people to ignore the page that mattered.
- **SLO-based alerting.** Alert on burn rate of your error budget, not arbitrary thresholds.