Is there any issue with Mixpanel MCP and Claude right now?

The knowledge sources do not mention any current or time-based outages or issues between Mixpanel MCP and Claude, so I can’t say whether there is an active problem “right now.”

What they do cover are common setup and usage issues you can check:

If you’re still seeing problems after these checks, the docs recommend contacting Mixpanel support via the help center.[Install troubleshooting]

kapa.ai Here's our current retry implementation: Proxy Retry Logic (MixpanelProxyClient) // Constants private val RETRYABLE_STATUS_CODES = setOf(429, 502, 503, 504) private const val RATE_LIMIT_BODY_MARKER = "Too many requests" private const val MAX_RETRIES = 6 private const val INITIAL_DELAY_MS = 2_000L // Start at 2s private const val MAX_DELAY_MS = 60_000L // Cap at 60s private const val JITTER_RANGE_MS = 5_000L // 1-5s random jitter // Retry loop inside forward() for (attempt in 0..MAX_RETRIES) { if (attempt > 0) { // Exponential backoff: 2s → 4s → 8s → 16s → 32s → 60s (capped) + 1-5s jitter val exponentialDelay = (INITIAL_DELAY_MS * (1 shl (attempt - 1))).coerceAtMost(MAX_DELAY_MS) val jitter = Random.nextLong(1_000L, JITTER_RANGE_MS + 1) val delayMs = exponentialDelay + jitter delay(delayMs) } val response = try { // Forward to api.mixpanel.com httpClient.post(targetUrl) { ... } } catch (e: Exception) { // Network failure → synthetic 502, will be retried MixpanelProxyResponse(statusCode = HttpStatusCode.BadGateway, body = """{"error": "proxy_error"}""") } // Normalize: 504 with "Too many requests" body → 429 // (Mixpanel returns 429 but intermediary LB/proxy surfaces it as 504) val normalizedStatus = if (status != 429 && body.contains("Too many requests")) 429 else status // Never retry 400 — validation errors always fail and waste rate-limit quota if (response.statusCodeValue == 400) return response // Success or non-retryable error → return immediately if (response.statusCodeValue !in RETRYABLE_STATUS_CODES) return response // Otherwise: retryable (429/502/503/504) → loop continues with backoff } // All 6 retries exhausted → return last response (biz layer logs + Slack alerts) return lastResponse Backoff Sequence (per attempt) ┌─────────┬──────────────┬─────────────────┬─────────────┐ │ Attempt │ Base Delay │ + Jitter (1-5s) │ Total Range │ ├─────────┼──────────────┼─────────────────┼─────────────┤ │ 1 │ 2s │ 1-5s │ 3-7s │ ├─────────┼──────────────┼─────────────────┼─────────────┤ │ 2 │ 4s │ 1-5s │ 5-9s │ ├─────────┼──────────────┼─────────────────┼─────────────┤ │ 3 │ 8s │ 1-5s │ 9-13s │ ├─────────┼──────────────┼─────────────────┼─────────────┤ │ 4 │ 16s │ 1-5s │ 17-21s │ ├─────────┼──────────────┼─────────────────┼─────────────┤ │ 5 │ 32s │ 1-5s │ 33-37s │ ├─────────┼──────────────┼─────────────────┼─────────────┤ │ 6 │ 60s (capped) │ 1-5s │ 61-65s │ └─────────┴──────────────┴─────────────────┴─────────────┘ Total retry window: ~2 minutes worst case before giving up. What We Handle - 429 / 502 / 503 / 504 → retry with exponential backoff - 504 with "Too many requests" body → normalize to 429, then retry (catches LB-masked rate limits) - 400 (validation error) → never retry, return immediately (per Mixpanel docs) - Network exceptions → treated as 502, retried with same backoff - Jitter → random 1-5s per attempt to desynchronize parallel requests

Your implementation is very close to Mixpanel’s recommended pattern and aligns well with the docs.

From the docs for /import and /track:

How your logic compares:

The docs don’t specify a maximum number of retries or total retry window; they just say to use exponential backoff up to 60s and keep retrying on 429/5xx.[Import rate limits] Your choice of 6 attempts (~2 minutes worst case) is a product decision and is not contradicted by the documentation.

So, based on the available docs, your retry strategy is fully aligned with Mixpanel’s recommendations, and there’s nothing in the knowledge sources that suggests a problem with what you’re doing.

kapa.ai on a safer side I am thinking to keep retrying till 10 minutes

The knowledge sources don’t specify any maximum total retry window (in minutes); they only prescribe how to retry, not how long:

They don’t say whether you should stop after 2 minutes, 10 minutes, or longer. That cutoff is left to your application’s requirements (latency SLOs, queue depth, user experience, etc.), and there’s no guidance in the docs that would make a 10‑minute retry window “unsafe” from Mixpanel’s perspective as long as:

So increasing your max retry window to ~10 minutes is a product/UX decision; the Mixpanel docs neither require nor forbid it.

kapa.ai I get this error also a lot 🔴 [PROD] Mixpanel Proxy Error: NETWORK_ERROR 🚨 <@S0ACHGFHGS0> cc: @Mani - Attention needed! Error Type: NETWORK_ERROR Path: track Message:

Failed to reach api.mixpanel.com

responseBody: {"error": "proxy_error"}