Usage and limits
Understand protective ingestion limits before treating them as a bill.
What is measured
The collector accounts for accepted telemetry events, serialized telemetry bytes, and replay bytes. Batch HTTP requests and individual events are different units: one network request can contain many events.
Monthly counters aggregate an owner's projects and reset at the next UTC calendar month. Deleting a project or rotating a key does not create a fresh account allowance. Use MCP get_telemetry_usage or the project's usage endpoint to read actual counters and limits.
Current implementation defaults
| Protective allowance | Free | Pro |
|---|---|---|
| Events / month | 200,000 | 2,000,000 |
| Telemetry bytes / month | 100 MiB | 1 GiB |
| Replay bytes / month | 10 MiB | 100 MiB |
Operators can override these defaults. The current collector recognizes Free and Pro entitlement for these protective caps. An Ultra card or usage estimate on the pricing page is not, by itself, an implemented collector entitlement or automatic overage billing.
Rate and payload limits
Default per-minute guards are 3,000 ingestion requests per IP, 600 per key, 1,200 per project, and 60,000 globally. They count requests, not individual events. The main ingest body limit is 256 KiB; SDK transport batches are smaller, at about 48 KB.
Rate or monthly-limit responses can pause or reject delivery. Bounded SDK queues may eventually expire or discard data under a prolonged block. Lower non-error sampling, inspect diagnostics, and use the configured account limits rather than assuming unlimited buffering.