An uploaded recording is kept for 30 days, then deleted. This is automatic, applies to every plan, and is not configurable today — there is no per-organization setting, no per-recording pin, and no API parameter that changes it.
That single sentence is the easy part. The rest of this page is the part that matters when you go looking for a six-week-old session: a recording is not the only thing a session leaves behind, and the sweep does not remove all of it.
What the clock is measured from#
The 30 days run from the moment the upload lands on the server — not from when the session was recorded, not from when it was last watched.
For most sessions those are minutes apart and the distinction never comes up. It does come up in one case: a session captured while the device was offline sits in the SDK's local queue until the SDK drains it — at the next launch, or the next time the app is foregrounded (see Uploading a Session). A session recorded on the 1st and uploaded on the 10th is deleted around the 10th of the following month, not the 1st.
Watching a replay does not extend the window. Nothing records a last-accessed time on a recording, so there is no way for viewing one to reset its clock — a session you watch daily ages out on exactly the same schedule as one nobody ever opened.
When the sweep actually runs#
Deletion is a scheduled job that runs once a day, not a continuous process. A recording is removed on the first sweep after it crosses 30 days, so in practice it can outlive the exact 30-day mark by up to a day. Nothing removes a recording early.
If the service is down when a recording ages out, that recording is not skipped — the job catches up on the next run rather than waiting for the following day's scheduled tick. The window is therefore best read as a ceiling that is enforced promptly, not as a timer that fires to the second.
What is deleted#
The recording row, in full. A recording's replayable payload is stored inline on that row rather than in separate blob storage, so deleting the row is what actually removes the session data — there is no second copy elsewhere to clean up, and nothing to reconcile afterward.
Gone with it:
- The replay itself — and note that for a session that hit an uncaught error, the replay stored on that row is the window around the error rather than the whole session. See The Error Capture Window for what that covers.
- The row's own metadata: platform, app version, duration, size, session id, and any tags or custom events attached to that session, along with the end-user id recorded on it.
- Its entry in the dashboard's recordings list. The list is a projection of the same rows, so a recording leaves the list at the same moment it leaves storage — it does not linger as an empty or broken entry.
Nothing else in the system holds a foreign key onto a recording, so this deletion does not cascade anywhere. That is also why the next section is longer than you might expect.
What is retained#
Exceptions, frozen frames, and frustration taps survive. Each captured exception, each frozen frame (a build+raster over 700ms), and each rage/dead/error tap cluster is stored as a first-class row in its own right, correlated back to a session by id rather than owned by the recording row. The retention sweep does not touch those tables. Their contents — exception type, message and stack trace, frame timings, tap positions and counts, and the end-user id on each — persist past the 30 days.
This has a consequence worth knowing before it surprises you: an exception from a session older than 30 days is still listed in the dashboard, but the "jump to this moment in the replay" action on it can no longer find a recording to open, and reports it as missing. The signal outlives the footage.
Everything that is not a recording is untouched: your organizations, client apps, API keys, collaborators, alert rules, and any uploaded assets are unaffected by retention. Assets in particular are uploaded once per client app and are not tied to the lifetime of any recording that referenced them.
Usage totals and billing#
Your usage figure is not an independent ledger that accumulates as recordings arrive. It is recomputed from scratch, roughly once a minute, by summing the duration of the recordings that still exist in the current billing period. That is deliberate — it is self-healing across restarts and renewals — but it means retention and usage are coupled:
If a recording is deleted while the billing period it was uploaded in is still open, its minutes leave the usage total. The 30-day window and a monthly billing period are close enough in length that this can happen near the end of a long month — a recording uploaded on day 1 of a 31-day period ages out before that period closes.
The effect only ever runs one way: a total can lose minutes this way, never gain them. If you are reconciling a usage figure against your own count of sessions, this is the discrepancy to look for first.
If you need a session kept longer#
There is no export or download today. The dashboard has no "download recording" action, and there is no supported way to pull a session out and archive it yourself. If a specific session matters beyond 30 days, capture what you need from it — notes, a screen capture of the replay, the exception details — while it is still there.
We would rather say that plainly than imply a workaround that does not exist. If long-term retention or export is something you need, it is worth telling us.
Deleting sooner#
Retention is an upper bound, not a minimum. Deleting a client app removes all of its recordings immediately, and deleting an organization removes everything belonging to it — both are irreversible and both take effect at once, without waiting for the 30-day sweep.