Most of these are shapes rather than allowances: they bound one request or one setting, and no plan changes them. What your plan does decide is at the bottom.
One request
| Limit | Value | Applies to |
|---|---|---|
| Events per batch | 100 | One POST to the ingest endpoint. |
| Batch size | 512 KB | The whole request body. |
| Event size | 32 KB | One event. Past it: event_too_large. |
| Properties per event | 32 keys | Past it: bad_properties. |
| Property nesting | depth 2 | A deeper object is refused, never flattened. |
| String property value | 1 KB | |
| Event name | 64 characters | [a-z][a-z0-9_]{0,63}. |
| Identifiers | 8–64 characters | ^[A-Za-z0-9_-]{8,64}$ for visitor, session and user ids. |
environment |
32 characters | [a-z][a-z0-9_-]{0,31}. |
| Event age | 7 days back, 10 minutes forward | Outside it: bad_occurred_at. |
Traits per identify call |
24 | Keys up to 40 characters. |
| Property value from an HTML attribute | 200 characters | data-sg-prop-* on a tagged element. |
A retried batch is de-duplicated by event_id for 24 hours, or the project's last 100,000 events, whichever is shorter. One project's flood shortens its own window and nobody else's.
Rate budgets
Sending events has two, because one address behaving badly and one key sending a lot are different problems:
| Budget | Ceiling | Why it exists |
|---|---|---|
| Per visitor | 600 requests a minute, from one address | To stop one runaway loop in one browser. |
| Per key | 30,000 requests a minute | A ceiling no real site reaches. A request carries up to 100 events, so this bounds requests, not events. |
Reading has one: a read key may make 120 requests a minute, and every answer carries X-RateLimit-Limit. A limited query comes back 429 with Retry-After: 60.
What happens at a ceiling
The request is refused with 429 and a Retry-After header saying how many seconds until it would be accepted — before its body is read, so no event in it is counted, stored or de-duplicated. Nothing is lost by the refusal itself:
- The browser tracker keeps the batch, waits the number of seconds the header names, and sends it again with the same event ids, so the second delivery is de-duplicated. While the tab stays open a throttled page view is late, not lost.
- A server-side sender must do the same. If your code drops a
429, that event is gone; Error codes has the retry rules.
Every refused request is counted against the project and shown under Tracking → Ignored traffic, so a key being throttled is visible to you before it is visible to us.
These ceilings exist to stop abuse of a key, not to meter you: your monthly allowance is a separate number, below, and going past it never causes a 429.
Per project
| Limit | Value |
|---|---|
| Active goals | 50 |
| Alerts | 20 |
| Alert window | 5 minutes to 7 days |
| Allowed origins on one key | 10 hostnames |
| Blocked countries (Shields) | 30 |
| Blocked paths (Shields) | 30 |
| Allowed hostnames (Shields) | 10 |
| Rows in one export | 1,000,000 — a larger range fails and names the cap |
| Export download window | 7 days |
What your plan decides
Your plan sets the monthly event allowance and how long events are kept — 90 days, 365, 730 or 1,095 by plan, stamped on each event as it arrives, so changing plan applies to what arrives afterwards.
Going past the monthly allowance does not stop collection. Every event is still accepted, counted and kept for the plan's retention. What the plan buys is the ability to read those events: past the allowance the analytics screens are replaced by a page that says so until the plan grows. Nothing is dropped and nothing needs re-sending.
Your own numbers, and what you have used this month, are on the workspace's plan screen. They are not repeated here, because they belong to the plan you are on.