# 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:

| Plan | Burst (events / minute, per project) |
| --- | --- |
| Hobby | 60 |
| Indie | 100 |
| Professional | 200 |
| Team | 500 |

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.

| Plan | Daily events (across all projects) |
| --- | --- |
| Hobby | 300 |
| Indie | 1,000 |
| Professional | 3,000 |
| Team | 20,000 |

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](/docs/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](/docs/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](/contact)** about a custom limit. See current limits and pricing
on the **[pricing page](/pricing)**.