observability-designlisted

# Observability Design Observability that can't answer "why did this break" during an actual incident isn't observability, it's a pile of dashboards. This skill designs it so the answer is actually there when it's needed, and designs the alerting so people still trust it after month three. ## Step 1 — Define SLIs tied to actual user-facing behavior A Service Level Indicator should measure what a user actually experiences (request success rate, latency at the percentile that matters, correctness of the result) — not an internal proxy like CPU usage that can be fine while the user-facing behavior is broken. Set the Service Level Objective as an explicit target against each SLI, and derive an error budget from it (how much failure is tolerable before it's a problem worth stopping other work for). ## Step 2 — Give each observability pillar its actual job - **Metrics** — for counting and aggregating (rates, durations, error counts) cheaply at high volume. - **Logs** — for the specific detail of a specific event, when you already know roughly where to look. - **Traces** — for following one request's actual path across service/async boundaries to see where time and errors accumulate. Using logs to do what metrics should (counting events by grepping/aggregating log lines) is expensive and slow exactly when speed matters most during an incident — assign the right pillar up front. ## Step 3 — Design trace propagation across every real boundary Context must survive not just synch