Log retention
How long logs stay searchable before they are archived or deleted. The reason last month's incident has vanished from your log tool.
See it
What it is
Retention is a per-stream policy: keep logs hot and instantly queryable for N days, roll them into cheap cold storage for months, then delete. Hosted platforms make the tradeoff impossible to ignore because they price it directly, but they do not all price it the same way. Ingestion, indexing, archive storage, and length of retention are separate billing dimensions, and which of them you are actually charged for depends on the product and the plan: some meter volume ingested, some meter indexed events, some bundle a fixed window and charge to extend it. Defaults are usually far shorter than people assume and the multiplier between a 7 day and a 90 day window can be large, so read your own provider's current pricing and defaults rather than trusting a remembered per GB per day rule of thumb.
Pick the window from how you actually work. Debugging an incident wants 7 to 30 days hot. Answering 'when did this start?' wants 90 days or more, but usually as metrics and aggregates rather than raw lines, which is cheaper by orders of magnitude. Compliance regimes (SOC 2, PCI, HIPAA) set floors on some log types and privacy law sets ceilings on others, so audit logs and app debug logs almost never deserve the same policy.
Gotchas: retention is the setting everyone discovers during an incident, at the exact moment the evidence expired. Check the default now, because it is usually shorter than you assume. Cold-tier logs are typically not searchable without a rehydration step that takes minutes to hours and costs money. And the fastest way to cut a log bill is not a shorter window, it is emitting less: sample the chatty debug lines and drop health-check and asset requests at the source.
Ask AI for it
Set up tiered log retention for this project. First identify the logging platform and cloud provider actually in use here, and implement this with that platform's own hot and archive lifecycle configuration rather than assuming S3 or any specific vendor. Define retention per log stream, with every window exposed as a named parameter I can change in one place: a short hot and searchable window for application and error logs, a shorter one for high-volume debug and access logs, and a long cheap archive tier for audit and security logs. Configure the archive step in compressed JSON using the provider's own storage class transition and expiry rules. Drop health-check and static asset requests before shipping, and sample debug-level logs in production. Document the per-stream windows and the rehydration steps in a README next to the config, and mark any legal or compliance retention floor as unresolved unless this project already states one, rather than inventing a requirement.