Docs Reference Rate limits

Rate limits

Per-plan rates on the ingest and data planes, fixed limits on the routes that take a password, and size and count ceilings.

Plane	Free	Pro
Ingest, per tenant	20 req/s, burst 40	200 req/s, burst 400
Data and account, per tenant	10 req/s, burst 20	100 req/s, burst 200

Enterprise limits are set per tenant. Over a limit the response is 429 with Retry-After in whole seconds.

Routes that take a password

Sign-up, login, account deletion and password-reset requests are limited in layers, so that one caller who knows your email cannot lock you out:

Per client. Thirty attempts from one address (an IPv4 address, or an IPv6 /64) across all of these routes, then one every two seconds.
Per email and client. A burst of five attempts for one email from one client (an IPv4 address, or an IPv6 /48), refilling at one per minute, so a drained burst is back in about five minutes. Account deletion also has its own per-second cap on top. Someone else guessing at your email drains their own copy of this budget, not yours.
Per email, wrong answers only. Login and account deletion share a looser budget of thirty wrong passwords per email from everywhere, refilling at one per minute. A correct password is refunded, so your own sign-ins never spend it, and draining it takes wrong guesses from several networks at once.
Per network, wrong answers only. A network (an IPv4 /24, an IPv6 /48) that fails heavily has its busiest callers refused. A caller making only a few attempts of its own is still let through.

Email-change requests that mail a verification link are capped per account: three, then one every ten minutes. Past it the answer is 429 with Retry-After.

Password-reset requests also have a per-inbox cap: at most three tokens are minted for one email in a burst, then one every five minutes. Past it the request still answers 200 and mints nothing, so the cap cannot be used to lock anyone out. Up to three reset tokens stay live at once, so an earlier one still works after a later request.

Routes that re-check the current password on a signed-in session (changing email or password, deleting a tenant, removing or demoting an owner) share a budget per session: five wrong passwords, then one per minute. Only wrong answers are charged.

A password-protected report’s unlock allows five wrong passwords per report, then one per minute. Test-firing a self-hosted box’s relay integration allows five, then one per minute per tenant.

Over any of these the response is 429 with Retry-After.

Sizes

Thing	Limit
Ingest `message`	64 KiB
Ingest `keys`	128 entries; names up to 128 bytes, values up to 4096 bytes
Ingest `tags`	64 entries, 256 characters each
Rule `match.tags`	64 entries, 256 characters each
Rule `match.sources`	64 entries
Rule `template_contains`	500 characters
Rule `conditions`	32; each `value` a string of at most 1024 bytes, a number, a boolean or null
Rule `identifier_keys`, `actions`	32 each
Rule minutes fields	525,600 (a year)
Escalation levels per rule	10
Action `body`	8 KiB
Action `headers`	32
Report `description`	4096 characters
Report `view_password`	8 to 72 bytes
Incident and report entry `content_md`	64 KiB of Markdown, rendering to at most 1 MiB of HTML
Log tail `limit`	200

Counts

Fixed ceilings, the same on every plan. A create past one is refused with 429 and an error naming the limit, for example max_rules_per_project: a project may hold at most 500 rules and 500 exist. There is no Retry-After: waiting will not free a slot; delete something first.

Thing	Limit
Rules per project	500
Sources per project	200
Webhooks and integrations per project, together	50
On-call schedules per project	50
Current or upcoming overrides per schedule	500
Reports per project	200
Entries per report	1000
Live API keys per member, per tenant	100
Pending invites per tenant	100

Actions have their own cap of 50 per project, refused with 403 and action limit reached.

Retention defaults on a self-hosted daemon

Flag	Default
`-retain-days`	7
`-max-logs-per-source`	10,000
`-resolved-horizon-days`	30