Most teams keep logs too long or not long enough. Here's how to set retention policies that balance debugging needs, compliance requirements, and storage costs.
The default answer to "how long should we keep logs?" is usually "as long as possible." That sounds safe. It isn't.
Keeping logs longer than you need burns money on storage, slows down search queries, and often gives you a false sense of security — you have six months of logs, but they're plain text that you can't efficiently query. Meanwhile, the one log you actually need from last week is buried under 40GB of health check noise.
Here's how to think about retention properly.
Before picking a number, get clear on why you're keeping logs at all:
Debugging. When something breaks, how far back do you typically look? For most teams running weekly deploys, 90% of post-mortem investigations stay within the last 7 days. The rare exception goes back 30 days. Almost no debugging session needs logs from 6 months ago.
Alerting. Alerts fire on recent data. Your anomaly detection and alert rules compare current patterns against a baseline window, typically 1–7 days. Long retention doesn't help here.
Compliance. This is the wildcard. PCI DSS requires 12 months. HIPAA is 6 years for certain records. GDPR complicates things further by requiring you to not retain personal data longer than necessary. Compliance retention should be handled separately from operational logs — usually in cold storage like S3, not in your live log management tool.
Startups and early-stage products: 14–30 days is usually enough. Your incident response cycle is fast, your team is small, and storage costs matter. You're more likely to need structured logging than long retention.
Growing SaaS products: 30–90 days. You're starting to see recurring patterns, doing more retrospective analysis, and investigating longer-running issues like slow memory leaks or gradual degradation.
Regulated industries: 12 months in live search + longer in cold archives. Keep what you need for debugging in your log management tool, and ship everything to S3/Glacier for compliance archiving.
High-volume services: Apply log sampling before you worry about retention. If you're ingesting 500GB/day of debug logs from a healthy service, the right answer isn't longer retention — it's reducing what you ingest.
| Plan | Retention | Best For |
|---|---|---|
| Free | 3 days | Prototyping, evaluation |
| Starter ($19/mo) | 14 days | Early-stage products |
| Growth ($49/mo) | 30 days | Growing SaaS teams |
| Pro ($149/mo) | 90 days | Scale-ups, complex systems |
| Enterprise | Custom | Regulated industries |
You can set retention per project in your project settings. If you have one service that's compliance-sensitive and another that's just debug noise, give them different projects with different retention.
Storage isn't free. More importantly, searchable storage isn't free. Every extra day of retention means your "search all logs in the last 90 days" query gets slower and costs more.
A practical framework: keep 30 days in your live log management tool (LogFlow, Datadog, whatever you use), and export older logs to cold storage if compliance requires it. The LogFlow API makes it straightforward to pull logs programmatically for archiving.
Not all logs deserve equal retention. Consider keeping these for less time:
Health check logs. GET /health 200 OK every 30 seconds adds up fast. Use ingestion rules to drop health check logs entirely, or sample them at 1%.
Debug-level logs in production. Debug logs are verbose by design. If you're logging at debug level in production (you probably shouldn't be), cap them at 3–7 days.
High-cardinality trace logs. If you're logging every SQL query or HTTP request at trace level, sample aggressively. You need enough to debug; you don't need all of them.
Error logs. Keep these for the full retention period. When a bug resurfaces after 6 weeks, you want the first occurrence.
Audit events. User logins, permission changes, data exports — these belong in an audit log with longer retention, separate from application logs.
Deployment events. Deployment markers let you correlate log changes with code releases. Keep these indefinitely — they're tiny and invaluable.
The fastest way to implement tiered retention in LogFlow: create separate projects for services with different requirements.
project: api-production → 30 days
project: api-debug → 7 days (verbose internal logging)
project: payments → 90 days (compliance-adjacent)
project: health-monitoring → 3 days (mostly noise)
This also makes billing predictable — you can see exactly how much storage each service uses and tune accordingly.
If you're unsure where to start: 30 days for most application logs, 90 days for error and audit logs. Review after 3 months. If you've never actually needed logs older than 2 weeks, drop to 14 days and save the money.
The goal isn't maximum retention. The goal is having the logs you need, in a form you can actually search, when something breaks at 2am.
Related: Why Log Management Matters for Startups · Reduce Logging Costs with Sampling · Structured Logging Guide
Free plan available. No credit card required. Up and running in 2 minutes.
Get started freeAlerting Best Practices: Stop Ignoring Your Own Alerts
Alert fatigue is the silent killer of incident response. Here's how to build alerts your team actually responds to.
Structured Logging: Stop Grep-ing Through Plain Text
Plain text logs break the moment you need to filter or alert. Structured logging with JSON gives you queryable logs from day one.
You Don't Need Datadog: Log Management for Startups That Ship Fast
Enterprise observability platforms charge enterprise prices. Here's what startups actually need — and why most are overpaying by 10x.