Rate Limits & Quotas

Ingestion is capped by two independent layers, bucketed differently and behaving differently when you go over:

• the per-minute burst limit is per project, and returns 429;
• the event quota is per account — shared by every project you own — and silently drops the report.

1. Per-minute burst limit

Smooths spikes — for example a bad deploy that makes thousands of users error at once. Bucketed per project (not per IP, not per key), so one noisy project can never eat another's burst budget. It scales with the project's plan:

Every response carries X-RateLimit-Limit and X-RateLimit-Remaining. Going over returns 429 with a Retry-After of a small number of seconds — back off briefly and retry.

2. Event quota

The hard cap on total volume. It belongs to your account, not to any one project: every project you own draws on the same pool.

The allowance is measured over a day, which bounds what a mistake can cost you. A runaway loop or a retry storm burns one day's allowance and stops; the allowance refills at midnight UTC and you are reporting again, without contacting us.

Exhausting the quota does not return an error. The server responds 200 with { "dropped": true, "reason": "quota" } (no card is created) and silently drops the report — a monitoring SDK should never surface a billing limit as a failure in the app it watches. There is no Retry-After; the quota resets at midnight UTC, so don't retry dropped reports.

You are not left to discover this from the drop. Everyone on the project who can act on it — the owner, admins and members, but not viewers — is emailed as the account passes 75%, 90% and 100% of the allowance, and each warning names the task cards drawing the most events so a runaway integration is easy to spot. Each warning is sent once per day at most.

One project cannot drain the whole pool

Because the pool is shared, a single leaked key or runaway project could in principle spend your entire allowance and leave every other project unable to report. It cannot: once an account has more than one active project, no single project may consume more than 80% of the account's pool.

This is a containment ceiling, not a budget. An account whose traffic is legitimately concentrated in one busy project is never squeezed by it, and an account with a single project is not subject to it at all.

Paused and archived projects

Only an active project accepts events. A paused or archived project is read-only, and that applies to the API exactly as it does to the dashboard: it answers 200 with { "dropped": true, "reason": "paused" } (or "archived"), creates no card, and spends none of your quota.

Pausing is reversible and frees the plan slot the project was holding, so it is how you choose which projects stay live when your plan has room for fewer than you have active. Resume the project and ingestion resumes with it. See Error Codes for what to do with each drop reason.

Designing for bursts

Errors are bursty by nature. Whether you call the API directly or use an SDK:

• Honour Retry-After and back off — never hammer a 429.
• Sample under load (sampleRate < 1) so a spike sends a representative fraction rather than every occurrence. This is the single most effective guard against a bad deploy spending a whole day's allowance in minutes.
• Bound concurrency so you never self-inflict the burst limit.
• Rely on deduplication — repeat reports collapse onto one card (matching on title or description), so a spike of the same error costs one card rather than thousands. The differing payloads are still kept beneath it as variants. See the API Reference.

There is no bulk endpoint — one card per request. The SDKs achieve throughput with a bounded-concurrency queue plus sampling and backoff, not a batch call.

Need more headroom?

Upgrade your plan for higher burst and event limits, or get in touch about a custom limit. See current limits and pricing on the pricing page.