design-observabilitylisted

# design-observability Make a service explain its behavior without requiring guesswork or a new deployment. Begin with the user journey and the decisions an operator must make. Tools and dashboards come after the questions, not before them. ## When to use Use this skill before launching a production service, after an incident exposed missing signals, or when operators cannot distinguish user failure from infrastructure noise. Do not collect data without a named operational question, retention rule, and owner. Never log credentials, tokens, full request bodies, or personal data by default. Redact or hash identifiers only when the result still supports a specific diagnosis and complies with policy. ## Preconditions - Name the critical user journeys, service owner, on-call path, and data-handling restrictions. - Gather current logs, metrics, traces, alerts, dashboards, incidents, and known blind spots. - Define normal traffic, important dependencies, and the actions operators are allowed to take. - Agree on a small set of measurable reliability objectives or interim targets. ## Procedure 1. For each critical journey, write the successful outcome and the failures users can observe. 2. Define a service level indicator for success, latency, freshness, or correctness. Specify numerator, denominator, exclusions, source, aggregation, and measurement window. 3. Set a service objective that reflects user tolerance and leaves room for safe change. Avoid false precision. 4. Def