Troubleshooting

Troubleshooting: Sessions Cut Short or Split

Why an AnyReplay recording can end early or split into several sessions: idle timeouts, new tabs, failed deliveries, oversized chunks, stop calls and app kills.

A recording that ends before the visit did, or one visit that shows up as several sessions, almost always has one of the causes below. Turning on debug: true tells you which, because the recorder logs the reason it stopped.

One visit, several sessions

Cause	What happens
30 minutes without activity	The next page load starts a new session. This matches common analytics behaviour.
A new tab or window	Session continuity lives in `sessionStorage`, which belongs to one tab. A link opened in a new tab is a new session.
A different origin	`app.example.com` and `www.example.com` have separate storage, so crossing between them starts a new session.
Storage unavailable	In privacy modes where `sessionStorage` throws, the recorder cannot remember the session across page loads.
React Native without `storage`	Ids are kept in memory, so every app launch is a new session. Pass AsyncStorage to resume within 30 minutes.

A recording that stops early

Debug message	Cause	What to do
`recording stopped: too_many_failures`	Deliveries kept failing — offline, a flaky network, or repeated `429` or `5xx` answers — and the page set `maxConsecutiveFailures`. Without it the recorder keeps retrying, waiting longer each time. SDKs before 0.2.0 stopped after five failures in a row.	Leave `maxConsecutiveFailures` unset unless you want the recorder to give up, and update an older SDK to 0.2.1.
`recording stopped: snapshot_too_large`	Browser SDK: the page itself, captured whole, is over 512 KB — typically huge inline data URLs or an enormous generated table.	Put `ar-block` on the element responsible (large generated tables, embedded base64 images).
`dropped one event of … KB`	A single change to the page was over 512 KB. It is skipped, the page is captured afresh, and recording goes on.	The same as above, if it keeps happening.
`recording stopped: rejected_413`	Ingest refused even small chunks — a self-hosted ingest with a very low `MAX_CHUNK_BYTES`. A `413` otherwise only makes the chunks smaller. SDKs before 0.2.0 stopped at the first one, after an outage sent the whole backlog as one request.	Update an older SDK to 0.2.1. Self-hosted: set `MAX_CHUNK_BYTES` back to the default 512 KB.
`recording stopped: rejected_403`	The page's origin was refused, for example a subdomain that is not on the list.	Add the domain to Allowed domains.
`recording stopped: rejected_402`	A limit was reached. This only refuses new sessions; a session already recording continues, so this appears on a new page that started a new session.	See session caps.
`recording stopped: stopped_by_page`	Your code called `stop()`.	Search your code for `anyreplay('stop')` or `.stop()`.
`recording stopped: consent_withdrawn`	`consent(false)` was called.	Check your consent banner wiring.

The last seconds are missing

On the web, the remaining buffer is sent with sendBeacon when the tab is hidden or closed. Browsers deliver beacons on a best-effort basis; an abrupt crash or a killed browser process can still lose the last few seconds. The tail goes as several small beacons, oldest first, so it fits the browser's 64 KB beacon budget, and a tab that is only hidden while the network is down keeps its buffer for when it comes back instead of sending beacons that would be lost.
On React Native, the buffer is flushed when the app goes to the background. If the operating system kills the app without that transition — a crash, or force quit from the app switcher while in the foreground — whatever was buffered since the last flush (up to 5 seconds by default) is lost. Lower flushIntervalMs if that matters.

Long stretches with nothing happening

A session keeps its clock while the visitor is idle, and the player shows idle stretches hatched on the timeline so you can skip them. This is not a cut; it is time the page was open with no activity.

Offline visitors

While offline the recorder keeps a bounded buffer — ten chunks' worth of events on the web, maxBufferedEvents on React Native — and drops the oldest events beyond it, so a long offline period cannot exhaust memory. The replay of such a session may be missing its middle rather than its end. Recording does not stop for failed deliveries (before 0.2.0 it stopped after five): it retries with a growing wait until the network is back, the backlog goes out in chunks of about 256 KB, and after a gap the screen is captured whole again so the replay picks up cleanly.