Frequent Mixpanel Proxy Errors: 504 Too Many Requests on Track and Engage Paths | Mixpanel Community

Mixpanel Community Icon

kapa.ai
APP
·
·
You’re hitting Mixpanel’s rate limits on the ingestion API.

From the error text:

responseBody: Too many requests → this corresponds to HTTP 429 “Too Many Requests”, which Mixpanel returns when rate limits are exceeded. [Rate limits]
Your proxy is surfacing it as a 504, but the body is clearly the Mixpanel rate‑limit message.

Relevant limits and behavior:

Ingestion (/track and /import) is limited to 2GB of uncompressed JSON per minute (~30k events/sec) per project, on a rolling 1‑minute window. [Import events; Track events]
When this is exceeded, Mixpanel returns 429 Too Many Requests and recommends exponential backoff with jitter and not retrying 400‑level validation errors. [Import events; Google Pub/Sub integration]

What you should do in your proxy / client:

1.
Detect rate limiting
Treat responses whose body is Too many requests (or HTTP 429 if you can see it before the proxy maps it to 504) as rate‑limit signals.
3.
Implement exponential backoff with jitter on retries
Start with ~2s delay, double up to ~60s, and add 1–5s random jitter before retrying. [Import events]
5.
Batch and throttle
Keep batches to ≤2000 events per request. [Track events]
Reduce the number of concurrent senders if you’re running many workers in parallel.
7.
Do not retry malformed payloads
If you ever see 400 errors from Mixpanel, log them and don’t retry; they count against rate limits and will always fail. [Track events; Quickstart code]
9.
Monitor volume spikes
Check if you recently increased traffic, added new tracking, or started a backfill that could be pushing you over the 2GB/minute limit.

If you share how your proxy currently retries (or if it retries at all), I can help you adjust the logic to align with Mixpanel’s recommended backoff pattern.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Mehul D.
·
·
Current Retry Implementation Proxy Layer (MixpanelProxyClient) - Retryable status codes: 429, 502, 503, 504 - Body-based detection: Also retries when response body contains "Too many requests" (catches 504s that are actually rate-limits from intermediary LBs) - Status normalization: If body says "Too many requests" but status is not 429, we normalize it to 429 before returning to the client - 3 retries with fixed delays: 30s → 1m → 2m (+ up to 25% random jitter) - Total retry window: ~3.5 minutes before giving up - 400 errors are never retried — logged as validation errors and returned immediately (per Mixpanel's recommendation) - Network exceptions (connection failures) are also retried with the same backoff kapa.ai Error Classification (Biz Layer) After all retries are exhausted, we classify and alert: - RATE_LIMITED — 429/503/504 or body-detected rate-limits - NETWORK_ERROR — genuine 502s (not rate-limit related) - VALIDATION_ERROR — 400s from Mixpanel (not retried) - MIXPANEL_API_ERROR — any other non-2xx What We Don't Do Yet - No gzip compression on forwarded requests - No batching/coalescing — each SDK request is forwarded 1:1 - No concurrency limiting — all incoming requests hit Mixpanel in parallel - No hot shard protection — no per-distinct_id daily event volume tracking
Mehul D.
·
·
kapa.ai
kapa.ai
APP
·
·
Sorry Mehul D., I'm not sure what you mean. Please try again. 👋
kapa.ai
APP
·
·
Your classification and “don’t retry 400s” behavior are aligned with Mixpanel’s guidance. The main gap vs. Mixpanel’s recommendations is how you’re retrying and how much load you’re sending.

From the docs:

Rate limit: 2GB uncompressed JSON/minute (~30k events/sec) per project. [Import rate limit; API rate limits]
Recommended pattern when you see 429 / 502 / 503: exponential backoff with jitter, starting at ~2s and doubling up to 60s, with 1–5s jitter. [Import rate limit; Track events]
Also recommended: gzip, batching (≤2000 events/request), and multiple concurrent clients until you start seeing 429s. [Import events; Quickstart best practices]

How your current setup differs

1.
Backoff pattern
You use fixed delays: 30s → 60s → 120s (with jitter) and then give up.
Docs recommend short initial delays (2s) and doubling up to 60s, with jitter, and continuing to retry 429/5xx as long as needed (no explicit “3 tries only” limit is given). [Import rate limit]

Effect: if you’re in a sustained high‑throughput period, you may still be hammering the API with many parallel requests that all retry on long, synchronized intervals, keeping you over the limit and generating lots of 429s/504s.

2.
No batching / gzip / concurrency control
1:1 forwarding from SDK → Mixpanel means:
Many small requests instead of up to 2000 events per request. [Import events; Track events]
No gzip (Content-Encoding: gzip) to reduce effective throughput. [Import events; Track events]
No concurrency limiting means you can easily exceed the 2GB/minute window during spikes.

Effect: you hit the global project rate limit more easily, and retries from many parallel requests keep you in a “rate‑limited storm”.

3.
Hot shard protection
Mixpanel itself will remediate hot shards by rewriting events to $hotshard_events and stripping distinct_id after 200K events per distinct_id per day (user analytics) or 1M per group id per day. [Hot shard limits]
Your proxy not tracking per‑distinct_id volume doesn’t directly cause 429s, but it can mean a single user or group is generating a disproportionate share of traffic, pushing you toward the global rate limit.

Concrete changes to consider

All of these are directly supported / recommended in the docs:

1.
Switch to exponential backoff with jitter

Something closer to:

Delays: 2s → 4s → 8s → 16s → 32s → 60s (cap at 60s), each with +1–5s jitter. [Import rate limit; Track events]
Continue retrying 429 / 502 / 503 (and 504s that you normalize to 429) while respecting your own overall timeout/SLA.
2.
Introduce batching and gzip in the proxy
Aggregate incoming events and send up to 2000 events per request. [Import events; Quickstart best practices]
Enable Content-Encoding: gzip on outbound requests to Mixpanel. [Import events; Track events]
4.
Limit concurrency from the proxy to Mixpanel
Cap the number of concurrent outbound requests (e.g., a fixed worker pool) so that even during spikes you don’t exceed the 2GB/minute window. [Import rate limit]
6.
(Optional) Hot‑shard awareness
Monitor per‑distinct_id daily volumes and alert or throttle if you approach 200K events per distinct_id per day or 1M per group id per day, to avoid flooding Mixpanel with pathological traffic patterns. [Hot shard limits]

If you’d like, you can paste a simplified version of your proxy’s retry code and I can suggest a concrete backoff sequence that matches the 2s→…→60s pattern from the docs.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.