observability-auditlisted

# Observability Audit A structured, evidence-based check of whether a system's logging, metrics, tracing, alerting, and on-call tooling actually let engineers tell what the system is doing right now and diagnose it quickly when something breaks. This is a static/config investigation, not a live chaos-engineering exercise, and it reports one table the user can act on. ## Ground rules - **Evidence or it didn't happen.** Every row needs a concrete pointer: a `file:line` for instrumentation code, the actual contents of a dashboard/alert-rule config file, a command's actual output (e.g. `grep` results, a metrics-endpoint scrape, a query against the logging backend), or an explicit note that this needs a human to confirm (e.g. "does the on-call rotation doc match who's actually paged" isn't verifiable from a repo alone). Never mark something ✅ because "a framework like this usually logs enough" or "they probably have dashboards somewhere" — either you found it, or you didn't. - **General engineering observability only — not the security-logging checks.** This skill answers "can we tell what the system is doing, and can we detect/diagnose a problem quickly." It does **not** duplicate `cybersecurity-check`'s `references/security.md` checks S26–S29 (audit logging for sensitive actions, no PII/secrets in logs, monitoring for security anomalies, documented incident-response process). If both skills are run on the same project, this skill's rows and those S26–S29