Observability & SLO Review Checklist
A review of whether a service is observable enough to operate, covering user-journey SLOs, golden-signal metrics, structured logs, distributed tracing, and symptom-based alerts linked to runbooks. It also checks telemetry cost and PII scrubbing.
When to Use This Checklist
Use this checklist when onboarding a service into production operations, after an incident exposed monitoring gaps, or as a periodic review. Observability is not just having metrics; it is being able to ask new questions of a running system and tie its behavior to user experience. This checklist evaluates whether a service can be operated and debugged under pressure.
How to Use This Checklist
Begin with SLOs, because they anchor everything else. Define them around user journeys, then ensure the underlying signals exist to measure them. Walk the three pillars: metrics for the golden signals, structured logs that are centrally searchable, and distributed traces that follow requests across service boundaries. Then scrutinize alerts, the part most often done badly. Every alert should be symptom-based, tied to SLO burn, and linked to a runbook. If an alert is not actionable, it is noise.
Do not ignore cost and privacy. High-cardinality metrics can blow up bills, and telemetry that leaks personal data is a compliance liability.
What Good Looks Like
SLOs are expressed in terms users would recognize, and error budgets visibly govern how aggressively the team ships. The golden signals are present for every critical service, logs are structured and consistent, and traces stitch requests across boundaries using shared semantic conventions. Alerts are few, sharp, and actionable, each with a runbook. Dashboards are built for the questions an on-call engineer asks during an incident. Personal data is scrubbed from telemetry, and the team reviews SLOs and alerts on a regular cadence so they stay relevant.
Common Pitfalls
The most pervasive pitfall is alerting on causes rather than symptoms, producing noise that buries real problems. Another is collecting telemetry without consistent conventions, so correlating metrics, logs, and traces becomes manual archaeology. Teams often define SLOs at the infrastructure level instead of around user journeys, measuring the wrong thing. Unbounded metric cardinality drives surprise costs, and unscrubbed telemetry quietly creates a privacy exposure.
Related Resources
Ground the review in SLOs, the four golden signals, and error budgets, and standardize instrumentation on OpenTelemetry semantic conventions for portable, correlatable telemetry.