Alert ingestion rate limits

Alert ingestion has rate limits applied, using a leaky-bucket algorithm. By default, each alert source accepts 120 events per minute. If you need higher rate limits, consider splitting its allowance based on a property of the incoming events, or discuss with your account manager. These limits are subject to change unless otherwise contracted.

​

Handling a 429

Going over returns 429 Too Many Requests, with the limit, what you have left, and when to retry in the error body. Retry from the sending tool: we drop the rejected event rather than queueing it, so no alert is created or updated. Every event draws on the allowance, including resolve events, deduplicated events, and events your source filters drop later. The alert source’s request log lists rate-limited requests.

​

Split a source’s allowance

Shard a source so that one noisy team or priority can’t consume its whole rate limit. Each distinct value at the path you choose gets its own allowance. To split a source’s allowance:

1. Open the alert source and expand Advanced settings
2. Under Rate limit sharding, choose Split the limit by a value in the payload
3. Enter a path into the payload, read like a deduplication key path (e.g., $.metadata.team or $.query_params.region)
4. Click Save

Point the path at a single value. A path landing on an object or an array does not split the rate limit. Rate limit sharding is supported for most alert sources. It is currently not supported for ticketing sources (Jira, GitHub, ServiceNow, Zendesk), PagerDuty, Opsgenie, or Sentry Issues.

​

FAQs