Event dropped by rate limiter warning in Sentry SDK

Question

When a Sentry server replies with HTTP 429, the client SDK emits an "Event dropped by rate limiter" warning. The response usually contains a Retry-After header that indicates how long the client should pause before sending further events. Some language bindings (e.g., JavaScript) parse and respect this header, while others (e.g., Python in older releases) ignore it and instead apply a fixed exponential back‑off strategy. This divergence can cause unpredictable event loss during traffic spikes and raises questions about the intended, documented behavior.
The goal of this inquiry is to clarify how each SDK handles the Retry-After header and why the implementation differs across bindings.
Key unresolved questions:

Does the current Sentry SDK for each language parse and honor the Retry-After header when a 429 response is received?
If some SDKs ignore the header, what is the rationale behind that design choice?
How can we standardize the retry strategy across all SDKs to reduce event loss during rate limiting?

Tasadduq Burney · Answer

Answer
The “Event dropped by rate limiter” warning is generated by the SDK’s own client‑side rate limiter, not by the network request. After a previous HTTP 429 response the SDK records a limit and subsequently drops matching envelopes locally until the limit expires.
Confirmed facts

The warning originates from the SDK’s internal rate‑limiting logic.
A 429 response may contain either a standard Retry‑After header, a Sentry‑specific X‑Sentry‑Rate‑Limits header, or both.
SDKs that understand X‑Sentry‑Rate‑Limits treat Retry‑After as a fallback because the Sentry header can express per‑category and per‑scope limits.
Older releases of some language bindings (e.g., Python < 0.18, early JavaScript SDKs) ignore Retry‑After and apply a fixed or exponential back‑off after transport failures.

Likely explanation for the divergence
The differences stem from independent per‑language transport implementations and release timelines. Early SDKs predated the X‑Sentry‑Rate‑Limits header, so they relied on a generic back‑off strategy. When the Sentry‑specific header was added, newer bindings incorporated it while retaining Retry‑After parsing, but older branches were not updated, leaving them to ignore the standard header.
Steps to verify and align behavior

Enable debug logging for the SDK (e.g., Sentry.init({ debug: true }) for JavaScript or logging.basicConfig(level=logging.DEBUG) for Python) and look for log lines that mention Retry‑After or X‑Sentry‑Rate‑Limits.
Point the SDK at a test endpoint that returns HTTP 429 with a known Retry‑After value (e.g., Retry-After: 5) and optionally an X‑Sentry‑Rate‑Limits header.
Observe whether subsequent events are delayed for the advertised interval or dropped immediately.
If the SDK ignores the header, check the installed version against the SDK’s changelog; upgrade to a release that includes header parsing (e.g., Python SDK ≥ 0.18, JavaScript SDK ≥ 7.0).
After upgrading, repeat the test to confirm the limiter now respects Retry‑After and drops events only until the expiry time.

Missing diagnostic detail
To give a precise upgrade recommendation, please specify the language binding and exact version of the Sentry SDK you are using (e.g., “sentry‑python 0.16.5” or “@sentry/browser 6.19.0”).

Event dropped by rate limiter warning in Sentry SDK

1 answer

Answer

Confirmed facts

Likely explanation for the divergence

Steps to verify and align behavior

Missing diagnostic detail

Your perspective belongs here.

0 question comments