Observability — What Claude Gets Wrong

You add tracing::info! and a /health that returns 200 OK and call the system "observable." In production: you can't distinguish slow from broken, your health check lies because it doesn't test downstream dependencies, you have no idea which service introduced latency because trace context isn't propagated, and your metrics are just structured logs you'll never query.

The Five Rules

1. Three pillars serve different purposes — logs for events, metrics for aggregates, traces for request flow
2. Health checks must test dependencies — a process that's up but can't reach the DB is not healthy
3. Propagate trace context across boundaries — HTTP headers, job queue metadata, message headers
4. Measure what matters for SLOs — latency histograms, error rates, saturation — not vanity counts
5. Detect degradation, not just failure — slow is often worse than down

Anti-Patterns You Default To