Limits

TinyReplay keeps a small, predictable footprint. These limits exist so the recorder can never block the page, grow memory unbounded, or overwhelm the server.

The numbers

SDK · recording

flushInterval	5000 ms	Batch flush cadence (configurable).
maxDurationMs	30 min	Recording auto-stops and flushes (configurable).
maskAllInputs	true	All input/textarea/select values masked at capture.
Events per batch	500	A flush never exceeds this; overflow rolls forward.
Event buffer ceiling	5000	Hard cap; new events dropped when a network stalls.
Beacon chunk	120 events	Unload flushes go out in small sendBeacon chunks.
Transport retry	1× after 2 s	Then the batch is dropped - never blocks the page.

Server · ingest

Events per request	1–500	Enforced by the ingest schema.
projectId length	1–64 chars	Validated on ingest.
token length	≤ 256 chars	Optional ingest token.
MAX_PAYLOAD_BYTES	5,000,000	Larger bodies get 413 (configurable).
RATE_LIMIT_PER_MIN	100 / IP	Ingest requests per minute per IP (configurable).

What happens at each limit

Batch size - 500 events

A flush never exceeds 500 events. rrweb's initial full snapshot can be large, so overflow rolls into the next flush.

Buffer ceiling - 5000 events

If the network stalls and the buffer fills, new events are dropped. The initial snapshot sits at the front of the buffer because a replay cannot live without it.

Recording duration - 30 minutes

At maxDurationMs the recorder stops and flushes. The page keeps working, untouched - recording ends.

Payload size - 5 MB (server)

Requests larger than MAX_PAYLOAD_BYTES get a 413. The 500-event batch cap keeps normal flushes well under this.

Rate limit - 100 / min / IP (server)

Beyond RATE_LIMIT_PER_MIN the server returns 429. The SDK retries once, then drops the batch.

All the server-side numbers are configurable

MAX_PAYLOAD_BYTES and RATE_LIMIT_PER_MIN are environment variables - see env vars and rate limits.

How batches actually get sent: Transport.