Mixpanel MCP: Get-Report degraded
This incident has been resolved.
The latest update from Mixpanel.
State
Resolved
Started
87 d ago
2026-08-06 07:19 UTC
Lasted
6 h 13 min
until 2026-08-06 13:32 UTC
Worst impact
Degraded
Timeline
4 updatesInvestigating
1 h 20 min 21%
Identified
33 min 9%
Monitoring
4 h 20 min 70%
Updates
Times in UTCAs posted by Mixpanel
This incident has been resolved.
A fix has been deployed and we're now monitoring the results. Report queries in the Mixpanel MCP server should be functioning normally. We'll continue to watch closely and provide a final update once we've confirmed full resolution.
The issue has been identified and fix is being implemented.
We are aware that the Get-Report tool in the Mixpanel MCP server is currently failing when called with skip_results: false. Report metadata is unaffected. We are investigating the issue and will provide updates as we have them.
Affected components
6Mixpanel in the last 90 days
Full historyIncidents in 90 days
5
Days with an incident
8
Median duration
6 h 13 min
This incident
About the median
Other Mixpanel incidents
All incidentsMixpanel·Degraded Service for Requests to decide.mixpanel.com
# **Mixpanel RCA: Requests to** [**decide.mixpanel.com**](http://decide.mixpanel.com) **Failed, October 15–21, 2026** ### **Summary** From Oct 15, 2026 to Oct 21, 2026, requests sent to `decide.mixpanel.com` and `api-decide.mixpanel.com` failed. This affected customers who sent event tracking, profile updates, or feature flag requests to this hostname, usually through a proxy. Events sent to this domain during this window were not received by Mixpanel and this data cannot be restored by Mixpanel. **Traffic sent to** `api.mixpanel.com`**,** `api-js.mixpanel.com,` `api-eu.mixpanel.com`**, and** `api-in.mixpanel.com` **were not affected.** Service on this hostname was unintentionally impacted while we were removing the `/decide` endpoint infrastructure. The hostnames were treated as part of the endpoint due to an incorrect understanding of system dependencies. To prevent this class of issue, we are adding traffic monitoring for the `decide.mixpanel.com` and `api-decide.mixpanel.com` hostn
Mixpanel·Temporary Data Ingestion Delay for US Projects
This incident has been resolved. The upstream issue with our cloud storage provider has been fixed, and our ingestion pipeline has been operating normally with no active delays. No events were lost throughout this incident, all affected data was fully reprocessed. Thank you for your patience throughout this incident.
Mixpanel·Degraded Query API Performance impacting US Projects
# Mixpanel RCA: Temporary Query Service Disruption for US Projects August 26, 2026 # Summary Between approximately **2:02 PM and 3:19 PM PT on August 26, 2026**, projects in the US region experienced failures loading reports and running queries through the Mixpanel UI and Query API. During this window, some queries in the region failed or returned errors. **No customer data was lost, and data ingestion was not affected.** All events continued to be collected and stored normally throughout the incident; once query service was restored, all reports reflected complete, accurate data with no customer action required. The cause was identified as a recently deployed internal tool for diagnostic query replay, a capability our engineers use to re-run copies of past queries to debug performance, which unexpectedly wrote large amounts of data to the disks of our query servers, consuming storage capacity the servers need to operate. When those disks filled, the affected servers took themselves ou
Mixpanel·Issues Populating Event Properties in dropdown menus
This incident has been resolved.
Follow Mixpanel
Your coding agent knows when Mixpanel is down, and tells you when a failure is theirs, not yours. You can also get Mixpanel incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "mixpanel" and tell me if Mixpanel has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=mixpanel/feed subscribe https://outages.cc/feed.xml?providers=mixpanelFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane