Sentry · Rate Limits
Sentry System Rate Limits
Sentry's REST API enforces two complementary mechanisms — fixed-window requests-per-second and concurrent in-flight requests. Limits are scoped per unique caller + endpoint combination (not per token, so generating extra tokens does not bypass them). Specific numeric thresholds are not published globally and vary per endpoint; current state is exposed via X-Sentry-Rate-Limit-* headers on every response. Sentry recommends webhooks over polling to avoid throttling.
2 Limits
Throttle: 429
Error TrackingObservabilityRate Limiting
Limits
Per-caller / per-endpoint rate caller/endpoint
see X-Sentry-Rate-Limit-Limit
Fixed-window count of requests by caller+endpoint. Reset epoch returned in X-Sentry-Rate-Limit-Reset.
Per-caller / per-endpoint concurrency caller/endpoint
see X-Sentry-Rate-Limit-ConcurrentLimit
Caps simultaneously open requests by caller+endpoint.
Policies
Caller-scoped enforcement
Limits are bound to the unique caller identity, not the token. Generating multiple tokens under the same identity does not raise the cap.
Header-driven adaptation
Always read X-Sentry-Rate-Limit-Remaining and X-Sentry-Rate-Limit-Reset to pace traffic. Concurrency caps require parallel-request governance.
Prefer webhooks over polling
Sentry explicitly recommends consuming events via webhooks rather than polling endpoints, to avoid hitting per-endpoint rate limits.
Backoff
On 429, back off until the time indicated by X-Sentry-Rate-Limit-Reset (UTC epoch); retries before that point will continue to be rejected.