How Long to Keep Session Replays (a Retention Policy That Holds Up)

Session replay data retention is a three-way tug-of-war. Support wants long lookback, because customers report bugs days or weeks after they happen. GDPR’s storage-limitation principle wants the shortest period you can justify, because replays are personal data almost by definition. And your disk — or your vendor’s per-GB meter — votes for shorter still. A defensible policy is wherever those three forces balance for your product, written down with reasons attached.

For most small SaaS teams, that balance lands at 30 days for ordinary sessions, longer for the diagnostically interesting ones. Here’s how to get there and make it survive an audit.

What each side of the triangle actually needs

Support’s real requirement is narrower than “keep everything forever.” Look at your ticket queue: the useful question is how old is the session by the time someone opens the replay? In my experience the distribution is front-loaded — most tickets arrive within a couple of days of the incident, and by the time a report is three or four weeks old the customer can’t tell you which day it happened anyway, so the replay is unfindable regardless of retention. A 30-day window covers the overwhelming bulk of real lookups. The tail exists, but it’s thin, and it’s mostly attached to bug investigations rather than fresh tickets — which is what the tiering below is for.

GDPR’s requirement is Article 5(1)(e): keep personal data no longer than necessary for the purpose. Note what it doesn’t say — no number. “Necessary” is yours to define and defend. A stated purpose of “diagnosing customer-reported defects” supports a window that matches your ticket-lookback reality; it does not support “indefinitely, in case marketing wants it later.” Shorter retention also quietly shrinks your breach blast radius and makes deletion-request handling mostly automatic, since data ages out on its own. (The full compliance picture — consent, masking, DPAs — is a separate topic; see session recording and GDPR compliance.)

The disk’s requirement is arithmetic. Compressed replays run a few hundred KB to a couple MB each; at tens of thousands of sessions a month, each additional month of retention is tens of gigabytes held at steady state. Self-hosting on a single node, that’s the difference between a disk you never think about and a quarterly “why is ingest failing” incident. On hosted tools, retention is often decided for you per tier — LogReplay’s free tier keeps 7 days, for example — which at least spares you the meeting.

A tiered session replay data retention template

Flat retention overpays on both sides: it keeps thousands of clean, boring sessions your support team will never open, while deleting the one session attached to an open bug at exactly day 31. Tier by diagnostic value instead:

Three tiers, no more. I’ve seen five-tier schemes; nobody could explain tier four during the review, which is worse than not having it — an unexplainable rule in a data policy is an audit finding waiting to be written.

Two implementation notes. First, “pinned” must be an explicit human action with the reason recorded, not a bulk default, or it becomes a retention loophole. Second, deletion should be automatic and boring — a lifecycle rule or nightly job, not a calendar reminder. A policy enforced by human memory is a policy you’re already violating.

What to write down so it survives an audit

The policy document is short. What auditors and DPO-shaped people actually check is whether these five things exist and agree with each other:

1. Purpose statement. One sentence: “Replays are retained to diagnose customer-visible defects.” Everything else derives from it.
2. The tiers and their periods, with the reasoning — “60 days for error-flagged sessions because bug investigations in our tracker have historically run 4–8 weeks.” A number with a reason is defensible; a bare number invites the question you can’t answer.
3. The enforcement mechanism. Name the actual lifecycle rule, cron job, or vendor setting. If you can’t point at the mechanism, the policy is fiction.
4. The exception path. Who may extend retention on a specific session, and where that’s logged. Legal holds happen; make them auditable rather than ad hoc.
5. The review date. Annual is fine. Policies with no review date fossilize, and a 2023-dated policy describing tooling you no longer run is nearly as bad as none.

Half a page total. Put it in the repo next to the infrastructure config, not in a wiki graveyard.

One closing opinion: when in doubt between two retention numbers, pick the shorter one. In ten years of operating systems that store user data, I have regretted keeping too much far more often than keeping too little — long-tail data is a liability with excellent camouflage, and nobody has ever thanked me for a ten-month-old replay.