The three decisions this is actually made of
Recording configuration is not one toggle - it is three separate decisions that get conflated: which sessions record (sampling and trigger rules), how long a recording survives (retention), and how someone finds a specific recording later (search and, more recently, AI-assisted replay search).
Which sessions get recorded
- Sampling rate - a flat percentage of sessions, useful for general UX monitoring where you do not need every session, only a representative sample.
- URL or event-based triggers - record only sessions that hit a specific page or fire a specific event (a checkout flow, an error state, a specific feature). This is almost always the better default for debugging work because it guarantees the sessions you actually care about are captured, instead of hoping they land in a random sample.
- Linked flags or cohorts - recording sessions only for users in a specific experiment variant or cohort, which keeps volume down while still covering the population you are actually studying.
Retention: the cost lever nobody checks
Recordings are one of the more storage-heavy things PostHog holds, and retention windows directly drive that cost. Exact retention defaults and configurable ranges are plan- and version-dependent - verify against current PostHog docs before sizing this rather than assuming last year's default still applies. The engineering question is: does anyone actually go back to look at a recording after 30 days, or is that data sitting there unread past a much shorter window?
| Use case | Recording strategy |
|---|---|
| General UX monitoring | Low sampling rate, shorter retention - it is a rolling health check, not an archive |
| Bug reproduction / support escalations | Event-triggered recording on error states, retention long enough to cover the support cycle |
| Onboarding or checkout funnel study | URL-triggered recording scoped to the funnel pages only, time-boxed to the study period |
| Experiment-linked replay | Recording tied to the flag/cohort under test, matched retention to the experiment window |
How to verify it worked
- Trigger the condition you configured (visit the URL, fire the event) from a test session and confirm the recording actually appears - trigger rules are easy to write with a syntax mismatch that silently records nothing or everything.
- Check that sessions outside your trigger conditions are not being recorded, if volume reduction was the point - a rule that is too broad defeats the purpose.
- Confirm a recording older than your retention window is actually gone (or, if you need it, that it was exported before expiring) - retention that is misconfigured either costs you money silently or deletes something someone needed.
- If using AI-assisted replay search, run a real query against a known recording and confirm it surfaces - this is a newer capability and its accuracy should be checked against your own data, not assumed from vendor marketing.