log-strategylisted

# Log Strategy Most teams either log too little to investigate anything or too much to find anything (and end up storing PII they didn't mean to). This skill is the middle path: enough to support incident response, not so much that the log becomes a liability of its own. Pairs with [`incident-response`](../incident-response/SKILL.md) (where logs get used) and [`gdpr-technical-controls`](../gdpr-technical-controls/SKILL.md) (where log privacy lives). ## When to invoke - Starting a new service or workflow - Investigation revealed missing fields ("we don't know what request triggered this") - Logs are leaking PII or secrets - Log volume is becoming expensive / unwieldy - Consolidating to a central logging stack (Loki, ELK, OpenObserve, hosted) - After an incident where the log was insufficient ## Three classes of log, three retention tiers Treat your logs as three distinct streams. Conflating them is where the trouble starts. | Class | Purpose | Typical retention | Storage tier | |---|---|---|---| | **Operational** | Debugging, performance, errors | 7–30 days | Hot index | | **Access** | Who hit what, when (webserver + app request log) | 30–90 days | Hot + warm | | **Audit** | Security-relevant events (auth, permission changes, sensitive actions) | 12 months+ | Append-only, immutable where possible | Costs and tools differ per class. Mixing them gives the audit log's slow-and-expensive retention to the operational stream and is the most common reason logging gets killed