Limits
Every limit here is enforced by the collector and shared with both SDKs from one definition, so the documented number and the enforced number cannot drift apart.
| Limit | Value | What happens at the edge |
|---|---|---|
| Event name | ^[a-z0-9_]{1,64}$ | Rejected and reported; the rest of the batch is still accepted |
| Properties per event | 2048 bytes of JSON | The event is rejected and reported |
| Events per batch | 100 | The SDK splits larger queues automatically |
| Distinct event names per project | 200 | New names beyond the cap are rejected and reported |
| Write key length | 64 characters | Longer is rejected |
| Anonymous identifier length | 64 characters | Longer is rejected |
| Clock skew | 7 days either side | Beyond it the event is rejected rather than filed under the wrong day |
| Queue depth | 500 events | The oldest are dropped first |
| Raw event retention | 90 days | Then deleted. Daily rollups are kept indefinitely |
Rejections are per event, not per batch
One malformed event does not lose the ninety-nine that travelled with it. The collector filters them out, accepts the rest, and reports what it dropped and why.
Only a malformed envelope — a bad write key, a missing client field — rejects the whole request, because in that case nothing in it can be attributed to anybody.
Why the distinct-name cap exists
Two hundred is generous for named events and immediately restrictive for generated ones. It exists to catch saved_session_${id} early, before a project has a hundred thousand event names nobody can group by. See naming.
Why the clock-skew window is seven days
Because a durable queue means events arrive late by design: an offline laptop, a suspended service worker, a device with a wrong clock. Seven days covers all three. The rollups recompute far enough back to include everything the window admits, so a late event still lands in the right day rather than being accepted and never counted.