Affected: All SDKs (server-side and client-side)
Overview
LaunchDarkly SDKs send analytics events to the events service (events.launchdarkly.com) at a configured flush interval. When the service responds with an HTTP error, the SDK drops the affected batch. This article covers the two response codes that most commonly cause dropped events, 400 and 429, and explains when each requires action.
Symptoms
Your SDK logs show an unexpected HTTP response from one of the LaunchDarkly events endpoints (
events.launchdarkly.com/events/bulk, events.launchdarkly.com/diagnostic, or the equivalent Relay Proxy endpoint). Typical signatures:Unexpected response status when posting events: 400
Unexpected response status when posting events: 429
With debug-level logging enabled, you may also see the full URL and payload size:
Posting events to https://events.launchdarkly.com/events/bulk ... response status 400
Note: These errors occur after the SDK has transmitted the payload and are distinct from the SDK-side Exceeded event queue capacity message, which fires locally when the in-memory queue overflows before events are sent.
Cause
Each HTTP response code indicates a different underlying condition. SDK behavior also varies by response code. Some are retried, others result in the batch being dropped immediately.
400 Bad Request
The events service rejected the payload as malformed. Common contributing factors include unusually large payloads, unexpected context attribute shapes, or SDK bugs in older versions. Isolated 400s against a flood of successful 200/202 responses are not necessarily actionable, the SDK's retry and buffering behavior typically absorbs a small loss rate without impacting flag evaluations, metrics, or the dashboard.
429 Too Many Requests
The events service is rate-limiting your account because event volume exceeds the allowed rate. SDKs back off and retry, so brief 429 bursts are usually self-correcting. Sustained 429s indicate a real volume issue that needs mitigation.
Solution
Follow these steps to diagnose and address HTTP errors from the events endpoint:
- Measure the rate of errors against successful responses.
- Enable debug-level logging on event processing.
- For 400 errors, inspect a representative payload.
- For 429 errors, reduce event volume or raise your event rate limit.
- When to escalate: If the error rate is a meaningful percentage of event traffic (for example, sustained 429s, or 400s representing more than a small fraction of event volume), open a support ticket and include: the SDK name and version, a representative log excerpt showing the response code, the approximate error-to-success ratio, and for 400s, a sample event payload captured via debug logging.
For dropped events caused by the SDK's own in-memory queue overflowing, read Error "Exceeded event queue capacity. Increase capacity to avoid dropping events" event queue capacity".