A 429 is a signal that the client is sending more traffic than the system should accept at that moment. The right response is usually to reduce unnecessary volume first, then tune retries and suppression where needed.
If /events Returns 429
- Honor
Retry-Afterwhen the SDK or transport exposes it. - Reduce duplicate capture at the source instead of retrying an infinite flood.
- Batch direct-ingest payloads when you control the transport.
- Audit logging loops, error retry loops, and repeated capture inside fallback UIs.
If Burst Guard Keeps Triggering
- Find the duplicate source that is crossing the threshold.
- Use a stable source identifier so the guard signal points back to the right service or worker.
- Tune thresholds and cooldown sampling only after you understand the actual noise source.
- Review SDK Burst Guard before changing runtime overrides.
Common Noisy Patterns
- Retry loops that capture every failed attempt separately.
- Handled exceptions that are logged and captured multiple times.
- Health checks or background jobs logging the same warning on every interval.
- UI error boundaries that re-render into the same failure repeatedly.
Recovery Plan
- Patch the noisy path at the source.
- Deploy and confirm traffic volume drops.
- Only then adjust burst-guard overrides or direct-ingest batching if the residual volume is still too high.