> ## Documentation Index
> Fetch the complete documentation index at: https://docs.observerbee.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reliability

> How the SDK avoids losing session data: local persistence, batching, and recovery.

Session data is only useful if it arrives. The SDK is built so that flaky networks, killed tabs, and slow backends do not cost you recordings.

## Events are persisted before they are sent

Every captured event is written to a durable outbox in the browser's IndexedDB before any network attempt. Rows are only deleted after the server has confirmed receipt. If the tab is killed mid-session, or the network is down for the entire visit, the events are still sitting in the outbox.

## Recording starts before the network handshake

When you call `init()`, recording starts immediately and synchronously. The handshake that creates the backend session runs in parallel. Events captured during that window (or during a full backend outage) go straight to the outbox and are delivered once a session exists. You never lose the first moments of a visit.

## Stranded sessions are recovered later

On each page load, after its own session is up, the SDK sweeps the outbox for leftovers from earlier sessions that never finished sending: a crashed tab, a laptop that went to sleep, a visit that ended offline. Whatever it finds is delivered under the original session, so the recording stays intact. Stranded data can be recovered up to 7 days after the session; older backlogs are no longer accepted by the backend.

## Batched delivery, beacon on close

Events are sent in batches: by default up to 100 events or 64KB per batch, flushed every 15 seconds (all configurable, see [Configuration](/sdk/configuration)). Failed sends retry with exponential backoff, and a circuit breaker backs off entirely when the backend is unreachable rather than hammering it.

When the tab is closed, hidden, or navigated away, buffered events are handed to the browser's beacon mechanism (`sendBeacon` / keepalive fetch), which delivers them even as the page tears down. If the beacon does not land, the outbox recovery above picks the events up on the next visit.

## Snapshots and checkpoints

The recorder captures a full DOM snapshot at the start of recording, then records incremental changes. To keep replays seekable and resilient, it also takes fresh checkpoint snapshots every 5 minutes or every 200 events, whichever comes first.

## SPA route changes

Client-side navigations are detected automatically via the Navigation API where supported, with `history.pushState` / `replaceState` patching and `popstate` / `hashchange` listeners as fallback. Each detected route change restarts the recorder so the new route begins with a fresh full snapshot. Rapid successive navigation events are debounced into a single restart.

## What this means for you

* You do not need to delay `init()` until the network is ready.
* You do not need special handling for SPAs, tab closes, or offline stretches.
* If a session looks truncated in the dashboard, check again later: the tail may arrive with the user's next page load, up to 7 days after the fact.