How Long You Keep Logs Is a Privacy Decision You Already Made
Access logs are the largest personal-data store most small projects have, and almost nobody chooses its retention on purpose.
Ask a small team how long they keep request logs and you will usually get one of two answers: "the platform default" or "forever, they are small". Both are decisions, and the second one is the largest undeclared personal-data collection most projects will ever have.
1. What is actually in the line
A standard access log entry holds the client IP, the timestamp, the method and path, the response status, the byte count, the referer, and the User-Agent. That is enough to identify a person in many cases, especially combined with a site that has few visitors: one IP plus one timestamp plus one path can be more identifying than a name.
2. Three legitimate reasons to keep them
- Debugging. Something broke at 14:32 and you want the request that caused it. This needs days, not years, and the useful part is usually the status, the path and the timing — not the full IP.
- Abuse and capacity. A traffic spike, a scraping campaign, a credential-stuffing attempt. This needs weeks in most cases, because patterns only appear over time.
- Legal obligation. Some jurisdictions require short retention of connection data for specific purposes. This is the only reason that can justify a fixed minimum, and it comes with conditions.
None of those reasons requires the full IP forever. If you can serve the purpose with a truncated address or a keyed hash, keeping the raw value is a choice, not a necessity.
3. Minimise when you write, not when you delete
The cheapest privacy improvement in any log pipeline is at ingest. Drop the last octet of IPv4 and the last 80 bits of IPv6 — that keeps city-level debugging and destroys most individual identifiability. If you need to correlate sessions, hash the address with a salt you rotate monthly: same-day correlation still works, cross-month correlation stops, and the salt never touches the log store.
Strip query strings you do not need. Half the personal data in a typical access log is in the query: tokens in URLs, email addresses in reset links, search terms. Logging the path template instead of the full URL removes the majority of it without losing the ability to debug routing.
4. Deleting is harder than it looks
A retention policy that says "30 days" but leaves backups for a year is a policy that does not exist. If your logs land in object storage with versioning, deletion means removing the versions too. If they are exported to a spreadsheet for a dashboard, that copy has its own retention. Derived aggregates are usually fine to keep — counts per hour per route are not personal data — which is a good reason to build the aggregate instead of retaining the raw rows.
5. What you can honestly promise
Do not write "we keep logs for 30 days" unless you have watched a row disappear. Pick a window you can enforce with a lifecycle rule, verify it once by querying for an old row, and put that number in the privacy policy. A verified 14 days is a better promise than an aspirational 90.
The same logic applies to third parties: your CDN and your error tracker hold copies too, on their schedules. Write down which providers see what and for how long, because that is the retention your users actually get.
ipbox.one keeps no per-visitor archive: the only stored value is a rate-limit counter that expires in about ninety seconds, and the privacy policy states it that way because it can be verified.
