Is Mixpanel down?

We’ve received reports that requests to decide.mixpanel.com are failing. Any traffic sent through decide.mixpanel.com may be affected, including feature flags and event tracking. To restore service now, point requests to api.mixpanel.com (US), api-eu.mixpanel.com (EU), or api-in.mixpanel.com (IN) depending on your project's Data Residency. We’re rolling out a mitigation and monitoring the results. We will post progress updates on our status page. If you have any questions, please contact support.

This incident has been resolved.

We've received reports that requests to decide.mixpanel.com are failing. Any traffic sent through decide.mixpanel.com may be affected, including feature flags and event tracking. To restore service now, point requests to api.mixpanel.com (US), api-eu.mixpanel.com (EU), or api-in.mixpanel.com (IN), depending on your project's Data Residency. We've rolled out a mitigation and are monitoring the results. We're seeing traffic restored. We will post progress updates on our status page. If you have any questions, please contact support.

This incident has been resolved.

# **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` hostnames. We will also require confirmed zero traffic at the hostname level before any hostname is removed. **We have since restored service on** `decide.mixpanel.com` . ### **What happened** Older Mixpanel SDKs called the `/decide` endpoint to fetch configuration for [**Legacy Automatically Tracked Mobile Events**](https://docs.mixpanel.com/docs/tracking-methods/sdks/ios#legacy-automatically-tracked-events). We [announced the endpoint’s retirement](https://docs.mixpanel.com/changelogs#2026-01-26), and for some time `/decide` has returned a `410` response. Separately, `decide.mixpanel.com` and `api-decide.mixpanel.com` acted as aliases for our standard API hostnames. For example, `decide.mixpanel.com/track` ingested events the same way `api-js.mixpanel.com/track` does. Some customers had set up proxies or SDK configurations to send their traffic to these hostnames. On October 15 at 7:40 PM CDT, during the final cleanup of the `/decide` endpoint, we removed the DNS records for `decide.mixpanel.com` and `api-decide.mixpanel.com` and removed both hostnames from our load balancer. Before making the change, we confirmed that traffic to the `/decide` endpoint had dropped to zero. However, our monitoring measured traffic by endpoint rather than by hostname. It therefore did not show that other requests, such as `/track` and `/flags`, were still reaching Mixpanel through these hostnames. From then on, all requests to this hostname failed, including endpoints such as `/track`, `/engage`, `/groups`, and `/flags`. * **Events and Profiles:** Events, Profiles, and any data intended for [Ingestion API endpoints](https://docs.mixpanel.com/reference/ingestion-api) to these hostnames during this window never reached Mixpanel, so we do not have a copy to restore. If you retained this data elsewhere, such as in proxy logs or your data warehouse, you can re-send it to Ingestion API’s [/import](https://docs.mixpanel.com/reference/import-events), [/engage,](https://docs.mixpanel.com/reference/profile-set) and [/groups](https://docs.mixpanel.com/reference/group-set-property). * **Feature flags:** Feature flag requests sent to these hostnames failed. SDKs served the last stored variant if one existed, or otherwise the fallback value configured in your code. ### Timeline \(Central Time, October 2026\) * **October 15, 7:40 PM CDT:** The hostname removal is applied. Requests to `decide.mixpanel.com` and `api-decide.mixpanel.com` begin failing. * **October 16, 5:22 AM CDT:** We receive the first customer report. It is initially understood to be related to the planned `/decide` retirement. * **October 21, 11:42 AM CDT:** Following an increase in customer reports about tracking failing for proxies, we identify the hostname removal as the cause. * **October 21, 12:26 PM CDT:** We restore the hostnames. `/decide` remains retired. * **October 21, 1:51 PM CDT:** We confirm traffic to the restored hostnames has recovered. * **October 21, 8:34 PM CDT:** The incident is resolved. ### **Root cause** 1. During the `/decide` retirement, `decide.mixpanel.com` and `api-decide.mixpanel.com` were unintentionally removed. 2. These hostnames had been configured to accept all API traffic, not only `/decide` requests, and this behavior was undocumented. 3. Our monitoring tracked traffic to the `/decide` endpoint but not to these hostnames, so pre-change checks did not show that other traffic was still active. 4. Because the hostnames and the retired endpoint share a name, early customer reports were initially interpreted as expected effects of the announced `/decide` retirement. This delayed escalation. ### **What we’re changing** * **Monitoring and alerting:** We are adding traffic and error-rate monitoring and alerting for `decide.mixpanel.com` and `api-decide.mixpanel.com`, so failures are detected automatically rather than through customer reports. * **Hostname audit:** We are auditing all public API hostnames and routing aliases for similar undocumented entry points, and we will review new hostnames and aliases before they go live. We are also tracking traffic that arrives on any unexpected hostname. * **Safer removals:** Before any future change to a public hostname, we will confirm zero traffic at the hostname level, and we will identify and contact any projects still using it. * **Customer communication:** We will give customers advance notice of material infrastructure changes that affect public hostnames, including publishing them on a timeline in our changelog. **Already deployed:** * Restored `decide.mixpanel.com` and `api-decide.mixpanel.com` * `/decide` remains retired #### **Common questions** * **Was my data affected?** Only if your SDK or proxy sent requests to `decide.mixpanel.com` or `api-decide.mixpanel.com` between October 15 and October 21. Data sent there during that window were not received and cannot be restored by Mixpanel. If you retained a copy of that data, you can re-send it to Mixpanel using our Ingestion API endpoints such as `/import` for events. * **Do I need to change anything?** No, the domains work again. We recommend using `api.mixpanel.com` \(or `api-eu.mixpanel.com` / `api-in.mixpanel.com` for EU and India data residency\) as your API domain. * **Is** `/decide` coming back? No. It remains retired as announced, and it is separate from the `decide.mixpanel.com` hostname. We’re sorry for the disruption. If you have questions about your project, please contact your account team or Mixpanel Support.

We are currently experiencing delays in our data ingestion pipeline, which is affecting real-time data for projects enrolled in the US projects, resulting in delays for a subset of projects. While no data is being lost, our engineering team is actively investigating the matter and working to restore real-time functionality as quickly as possible. We appreciate your patience during this time. If you have any questions, please contact support.

The issue has been identified and a fix is being implemented.

We've identified the cause of the ingestion delay as an upstream issue with our cloud storage provider, Google Cloud, impacting a subset of US projects. Google has confirmed this as a high-priority issue on their end but hasn't provided an ETA yet. We've deployed mitigations to ensure a smooth recovery once it clears. No events are being lost. This is strictly an ingestion delay, all affected data will continue to be reprocessed once the issue is resolved.

Our metrics show ingestion is caught up and no longer experiencing delay. Google has not yet confirmed resolution of the underlying upstream issue on their end, so we’re continuing to monitor closely in case of recurrence.

We are continuing to monitor for any further issues.

No change since our last update, we continue to observe no active ingestion delay on our end, and all systems remain healthy. We’re continuing to monitor closely.

We are continuing to monitor for any further issues.

Systems have remained stable with no recurrence of the ingestion delay. We’re keeping a close eye on things while we wait for final confirmation from our upstream provider.

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 is experiencing degraded Query API performance, resulting in HTTP 500 responses when querying reports for projects with US Data Residency. Projects with EU and IN Data Residency remain unaffected. We appreciate your patience while our engineers work to restore normal functionality. We will post progress updates on our status page. If you have any questions, please contact support.

The issue has been identified and a fix is being implemented.

A fix has been implemented, and we're seeing improved success rates for the Query API. We will continue monitoring to ensure stability.

This incident has been resolved.

# 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 out of service. Service was restored, the impacted servers were brought back online, and the internal tooling was disabled. The remediations below add storage safeguards to remove internal tooling's ability to consume resources on query servers, and are designed to prevent this class of failure from happening again in the future. # What happened Mixpanel's query engine runs on a fleet of servers that each use a set of local storage volumes to cache the data needed to answer queries quickly. Separately, our engineers use diagnostic query replay tooling, a capability our engineers use to reproduce and debug query performance. While applying the diagnostic query replay tooling to a large, complex query, a software bug caused the query replay captures to fan out across the entire fleet instead of remaining confined to a single server. Additionally, it caused far more data than intended to be saved without timely eviction on a single server. Two factors then widened the impact of the issue: * A single full storage volume took a server fully out of service. Each server treats its cache as unhealthy if any one of its storage volumes crosses a usage threshold, even when all other volumes are healthy. The replay data was written to one specific volume on every server, so servers across the region failed their health checks nearly simultaneously. * Cleanup limits did not account for data size. The safeguard limiting replay data on disk counted items at the application level rather than bytes at the filesystem level, so a small number of unexpectedly large captures passed the check while consuming most of the volume’s capacity. Together, these allowed a single debugging workflow that normally has a negligible footprint to interrupt production query serving across the US region. # Timeline \(Pacific Time, August 26, 2026\) * **2:00 PM** — First oversized diagnostic replay capture was written; storage volumes began to reach their capacity and query success rate began to drop shortly after. * **2:17 PM** — Automated alerting paged the on-call engineer; investigation began immediately and additional engineers were engaged. * **2:39 PM** — Status page incident posted; in-app banner displayed at 2:40 PM. * **2:53 PM** — Root cause identified; recovery efforts began on the first affected server group. * **3:19 PM** — Query service restored for the vast majority of traffic; the final server group fully recovered at 3:27 PM. * **3:45 PM** — Incident resolved after a stable observation period. The diagnostic replay tooling that triggered the issue was fully disabled the same evening. # Root cause 1. **A software bug in our query replay tooling caused unbounded writes to production storage.** A recently deployed capability for reproducing queries mishandled a particular class of complex query, causing captures to spread to every query server in the region and to write far more data to the affected volumes than the design assumed. 2. **Replay files consumed disk capacity that query serving depends on.** The replay tooling wrote its files to the query servers' local disks, so runaway replay data exhausted storage capacity the servers need to answer queries. 3. **Safeguards only partially accounted for the behavior.** The cleanup policy for diagnostic replay data limited the number of items on disk, but not their total size, so it did not engage. Alerting on storage volumes flagged the growth but was not escalated as critical on a per-server basis, which delayed detection until query failures began. # What we're changing The end state we are building toward: internal diagnostic query replay data stored in dedicated object storage, placing no load on production query servers. Already deployed: * **Disabled the internal tooling** that caused the incident, and remediated the underlying issue so diagnostic captures are confined to a single server and the specific query class is handled correctly. * **Documented the targeted recovery procedure** used during the incident, i.e., clearing only the affected storage volume rather than restarting full server groups, in our operational runbooks, shortening recovery time if any volume’s capacity runs out in the future. In progress: * **Filesystem-level, size-based limits on diagnostic replay data**, capping total bytes on disk rather than item counts, so oversized captures are rejected or evicted before they can affect the volume’s capacity. * **Stricter storage alerting**, escalating per-server volume saturation as critical before it can affect query health checks. * **Moving query replay data to dedicated object storage,** so it consumes no resources on production query servers. # Common questions * **Was any data lost?** No. Data ingestion was unaffected throughout the incident: events continued to be collected, queued, and stored normally. Only the ability to query was interrupted. Once service was restored, all reports reflected complete data. * **Were saved reports, dashboards, or project settings affected?** No. The incident affected query execution only. Nothing stored in your project changed. * **Why did it affect multiple US projects at once?** The oversized diagnostic replay data written to every query server's disks at nearly the same time, and each server removes itself from service when any one volume fills. Preventing internal tooling from consuming query-server storage is a core part of our remediation work. * **How is this prevented going forward?** The tooling issue is resolved and the tooling remains disabled until size-based limits are in place. Storage alerting is being tightened so saturation is caught before it affects query serving. Structurally, we are moving diagnostic data off production query servers entirely, so internal debugging data will consume no storage on the servers responsible for queries processing. We apologize for the disruption and for the time reports were unavailable. Please reach out through your account team or support with any questions.

We are currently experiencing issues with populating event properties in dropdown menus. We appreciate your patience while our engineers work to restore functionality. If you have any questions, please contact [email protected]

We are continuing to work on a fix for this issue.

We are continuing to work on a fix for this issue.

A fix has been implemented and we are monitoring the results.

This incident has been resolved.