Monitoring tells you that something happened; observability lets you understand why. And above all it lets you alert on the right symptoms: the ones the user feels.

The three pillars

Metrics, logs and traces — ideally collected with a standard like OpenTelemetry, so you are not tied to a vendor. Traces, in particular, show the journey of a single request across services: that is where you find the bottlenecks.

Alert on SLOs, not on numbers

An SLO (Service Level Objective) is the promise you make to the user: for example “99% of requests under 300ms”. The alert should fire when you are burning your error budget, not when a chart has a harmless spike.

# % of fast requests (latency SLI)
sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m]))
  / sum(rate(http_request_duration_seconds_count[5m]))

The result: fewer alerts, but the ones that arrive really matter. The team stops ignoring them — and that is half the battle.