Mixpanel Outage History

Started Oct 21, 2026, 06:04 PM UTC· resolved Oct 21, 2026, 08:15 PM UTC

1. monitoring Oct 21, 2026, 06:04 PM UTC

   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.

2. resolved Oct 21, 2026, 08:15 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 08, 2026, 04:32 PM UTC· resolved Oct 09, 2026, 12:22 AM UTC

1. investigating Oct 08, 2026, 04:32 PM UTC

   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.

2. identified Oct 08, 2026, 05:32 PM UTC

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

3. identified Oct 08, 2026, 06:31 PM UTC

   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.

4. monitoring Oct 08, 2026, 07:30 PM UTC

   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.

5. monitoring Oct 08, 2026, 08:30 PM UTC

   We are continuing to monitor for any further issues.

6. monitoring Oct 08, 2026, 09:30 PM UTC

   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.

7. monitoring Oct 08, 2026, 10:30 PM UTC

   We are continuing to monitor for any further issues.

8. monitoring Oct 08, 2026, 11:30 PM UTC

   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.

9. resolved Oct 09, 2026, 12:22 AM UTC

   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.

Read the full incident report →

Started Aug 26, 2026, 09:39 PM UTC· resolved Aug 26, 2026, 10:45 PM UTC

1. investigating Aug 26, 2026, 09:39 PM UTC

   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.

2. identified Aug 26, 2026, 10:11 PM UTC

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

3. monitoring Aug 26, 2026, 10:28 PM UTC

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

4. resolved Aug 26, 2026, 10:45 PM UTC

   This incident has been resolved.

5. postmortem Sep 08, 2026, 06:25 PM UTC

   # 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.

Read the full incident report →

Started Aug 19, 2026, 11:20 PM UTC· resolved Aug 20, 2026, 03:05 AM UTC

1. identified Aug 19, 2026, 11:20 PM UTC

   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]

2. identified Aug 19, 2026, 11:23 PM UTC

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

3. identified Aug 20, 2026, 01:04 AM UTC

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

4. monitoring Aug 20, 2026, 02:52 AM UTC

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

5. resolved Aug 20, 2026, 03:05 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Aug 06, 2026, 07:19 AM UTC· resolved Aug 06, 2026, 01:32 PM UTC

1. investigating Aug 06, 2026, 07:19 AM UTC

   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.

2. identified Aug 06, 2026, 08:39 AM UTC

   The issue has been identified and fix is being implemented.

3. monitoring Aug 06, 2026, 09:12 AM UTC

   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.

4. resolved Aug 06, 2026, 01:32 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 22, 2026, 08:03 AM UTC· resolved Jul 22, 2026, 02:47 PM UTC

1. investigating Jul 22, 2026, 08:03 AM UTC

   We are currently experiencing issues with the Mixpanel agent within the webapp. Our engineering team has been alerted and is investigating the issue and working to restore its functionality. We appreciate your patience as we work to resolve this matter. If you have any questions, please contact support.

2. investigating Jul 22, 2026, 09:52 AM UTC

   the team continues to investigate the issue and next steps. Thanks for your patience.

3. monitoring Jul 22, 2026, 10:55 AM UTC

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

4. resolved Jul 22, 2026, 02:47 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 29, 2026, 07:47 PM UTC· resolved Jun 30, 2026, 03:30 AM UTC

1. investigating Jun 29, 2026, 07:47 PM UTC

   Mixpanel is experiencing degraded performance with our Query API, including increased latency. You may see slow-loading reports or query errors. 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.

2. identified Jun 29, 2026, 09:04 PM UTC

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

3. identified Jun 29, 2026, 10:42 PM UTC

   Query latency has stabilized, though our team continues to investigate the underlying cause of the degraded performance. We will continue to post updates as our investigation progresses. Thank you for your patience.

4. monitoring Jun 30, 2026, 02:15 AM UTC

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

5. resolved Jun 30, 2026, 03:30 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 03, 2026, 08:05 PM UTC· resolved Jun 03, 2026, 09:27 PM UTC

1. investigating Jun 03, 2026, 08:05 PM UTC

   Mixpanel is currently experiencing a disruption in the ability to invite and delete internal users within organizations. We appreciate your patience while our engineers work to restore this functionality. If you have any questions, please contact [email protected]

2. identified Jun 03, 2026, 08:17 PM UTC

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

3. resolved Jun 03, 2026, 09:27 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 02, 2026, 11:02 AM UTC· resolved Jun 02, 2026, 04:53 PM UTC

1. investigating Jun 02, 2026, 11:02 AM UTC

   We are experiencing delays with our data ingestion and shuffling pipeline to projects with all projects. No data is being lost but as a result, real-time data is delayed. We appreciate your patience while our engineers work to restore real-time functionality. If you have any questions, please contact support

2. identified Jun 02, 2026, 12:31 PM UTC

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

3. monitoring Jun 02, 2026, 02:31 PM UTC

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

4. resolved Jun 02, 2026, 04:53 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 19, 2026, 07:03 PM UTC· resolved May 19, 2026, 09:18 PM UTC

1. investigating May 19, 2026, 07:03 PM UTC

   A subset of users are currently facing issues accessing boards that they previously had access to view. Our Engineering team is actively investigating and will update shortly.

2. identified May 19, 2026, 07:10 PM UTC

   The issues has been identified and a fix is being implemented. As a workaround boards can be explicitly shared with users who are having issues viewing them currently.

3. monitoring May 19, 2026, 08:23 PM UTC

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

4. resolved May 19, 2026, 09:18 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 14, 2026, 11:17 PM UTC· resolved May 16, 2026, 02:50 AM UTC

1. investigating May 14, 2026, 11:17 PM UTC

   We are experiencing degraded performance with our Query API. You may see incomplete query results, query errors, or data discrepancies. 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.

2. identified May 14, 2026, 11:48 PM UTC

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

3. identified May 15, 2026, 12:18 AM UTC

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

4. identified May 15, 2026, 12:49 AM UTC

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

5. identified May 15, 2026, 01:49 AM UTC

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

6. identified May 15, 2026, 02:49 AM UTC

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

7. identified May 15, 2026, 03:49 AM UTC

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

8. identified May 15, 2026, 08:18 AM UTC

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

9. identified May 15, 2026, 10:19 AM UTC

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

10. identified May 15, 2026, 12:28 PM UTC

    We've continued to make progress on the issue affecting some US projects. Query success rates have returned to normal levels, and the related processing delays have also recovered. A subset of affected projects may still see incomplete data in query results while our recovery process runs. We're actively working on this and will share another update in 2 hours. Impact remains limited to our US region. We do not currently believe any data has been permanently lost.

11. identified May 15, 2026, 02:31 PM UTC

    Recovery is progressing well. Query success rates remain at normal levels, and missing data has now been restored for a portion of affected projects. We're continuing the recovery process for the remaining affected projects and currently estimate full recovery within approximately 3–5 hours. Some customers may still see incomplete data in query results until this work is complete.

12. identified May 15, 2026, 04:37 PM UTC

    We are continuing to work on resolving this issue. Our current estimate for full recovery is approximately 3–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

13. identified May 15, 2026, 06:47 PM UTC

    Recovery is continuing to progress and query latency has returned to normal levels. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

14. identified May 15, 2026, 07:56 PM UTC

    We are investigating an increase in query latency that appears to be unrelated to the ongoing recovery. You may experience slower-loading reports. Our team is actively looking into the cause and we will provide an update shortly. Recovery is continuing to progress. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

15. identified May 15, 2026, 09:23 PM UTC

    Query latency has returned to normal levels. We are continuing to monitor.

16. identified May 15, 2026, 10:14 PM UTC

    Query latency has returned to normal levels and has been resolved. Recovery is continuing to progress, and our current estimate for full recovery is approximately 4–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

17. identified May 16, 2026, 12:17 AM UTC

    Recovery is continuing to progress. Our current estimate for full recovery is approximately 1-2 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

18. monitoring May 16, 2026, 01:52 AM UTC

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

19. resolved May 16, 2026, 02:50 AM UTC

    This incident has been resolved.

20. postmortem May 21, 2026, 09:43 PM UTC

    # Mixpanel RCA: Transient Data Access Issue, May 14, 2026 ## Summary On Thursday, May 14, 2026 at approximately 2:30 PM PT, a routine but infrequent cleanup operation in Mixpanel's storage system mistakenly removed a portion of production data files in addition to the unused files it was intended to remove. Some customers experienced query errors during the hours that followed. We detected the issue within minutes, deployed mitigations the same evening that returned query success rates and latency to normal, and restored the affected files from backup by 5:15 PM PT on Friday, May 15. Mixpanel's ingestion pipeline was not affected and no event data was lost in transit. ## What happened This incident was triggered by a storage cleanup procedure that runs periodically to remove files no longer referenced by Mixpanel's metadata. The procedure was more involved than usual: it followed a recent enhancement to our file storage strategy that left a set of unused files behind in our storage backend, and addressing them required extending our standard cleanup approach to cover a new code path. As part of executing this extended cleanup, an engineer generated the list of files to delete using a SQL query whose date filter was not strictly earlier than the reference snapshot it was being compared against. As a result, a small set of legitimate production files that had been written in the gap window between the snapshot and the filter date were incorrectly classified as unused and removed. The deletion ran for roughly half an hour before internal alerting caught the resulting query failures and the operation was stopped. The trigger was operator error against an ambiguous runbook, not a defect in the live serving path or in our ingestion pipeline. ## Customer impact Impact unfolded in two phases. The first phase ran from Thursday at approximately 2:30 PM PT until 8:11 PM PT — roughly five and a half hours. During this window, customers across the platform may have seen slower or failed queries when their requests touched files that had been deleted. The breadth and severity varied by project depending on which data each query touched. By 8:11 PM PT, mitigations had fully rolled out — queries automatically retried against an alternate availability zone, and a fallback path was put in place to serve missing files from a backup datastore. After this point, query success rate and latency returned to normal. The second phase lasted from 8:11 PM PT Thursday through approximately 5:15 PM PT Friday, May 15. During this window, fewer than 2% of customers were still affected — specifically, those whose deleted files had not yet been fully restored from backup. The vast majority of these files were recovered by Friday afternoon. A small number of projects \(under 30\) had files that could not be fully recovered from backup, and we are following up with those accounts directly. ## Timeline \(Pacific Time\) * May 14, 2:30 PM — Cleanup operation begins * May 14, 3:11 PM — Internal alerting flags query failures; the cleanup operation is stopped within minutes * May 14, 4:07 PM — Status page banner posted * May 14, 4:45 PM — Mitigation deployed: queries automatically retry against an alternate availability zone * May 14, 7:12 PM — Mitigation deployed: queries fall back to a backup datastore for missing files * May 14, 8:11 PM — Query success rate and latency fully restored to normal levels * May 15, 5:15 PM — File restore from backup complete; status page banner resolved ## Why this happened Several contributing factors lined up. The runbook for this cleanup procedure had ambiguous wording around the ordering and timing of its inputs. It had been recently authored to handle the new file-storage code path and had not gone through a formal review before being used. Our cleanup tooling did not programmatically enforce the safety invariant that the date filter must be strictly before the reference snapshot. That invariant lived only in operator-authored SQL. The extended cleanup was being executed in parallel across two storage layers by two different engineers, which increased the room for error. ## What we're doing to prevent recurrence We have already made or have actively in flight the following changes. We have updated the cleanup runbook with explicit guidance on input timing, required safety buffers, and an enforced review process for any runbook covering a destructive operation. We are adding programmatic safeguards to our cleanup tooling so that an input set whose date filter is not safely before the reference snapshot is rejected before any deletion occurs, along with a reconciliation step that flags any production-referenced file before deletion proceeds. Destructive cleanup operations will now run in phased stages, starting with internal projects and pausing for a holding period before any broader execution. Destructive storage operations now require a second engineer to sign off on the exact deletion set and to be present during execution, matching the practice we already follow for database migrations. Longer term, we are working to eliminate the manual portion of this cleanup procedure entirely and route it through our existing automated cleanup infrastructure, so the class of failure that produced this incident is no longer reachable through human input. ## Closing Reliability and data integrity are foundational to the trust our customers place in Mixpanel, and we recognize the impact this incident had on the teams who rely on us. We are sorry for the disruption. If you have questions about how this incident may have affected a specific project, please reach out to your account team or Mixpanel Support.

Read the full incident report →

Started May 13, 2026, 04:34 PM UTC· resolved May 14, 2026, 01:35 PM UTC

1. identified May 13, 2026, 04:34 PM UTC

   Data Volume Monitoring is again experiencing degraded performance due to a recurring upstream provider disruption. We're mitigating now.

2. identified May 13, 2026, 09:40 PM UTC

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

3. resolved May 14, 2026, 01:35 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 06, 2026, 12:00 AM UTC· resolved May 06, 2026, 08:04 PM UTC

1. investigating May 06, 2026, 12:00 AM UTC

   A subset of projects are experiencing issues exporting data to the Snowflake warehouse via Mixpanel pipelines. We are currently investigating this issue.

2. identified May 06, 2026, 09:32 AM UTC

   We have identified the issue affecting Snowflake pipeline exports for a subset of projects, and our engineering team is working on a resolution.

3. resolved May 06, 2026, 08:04 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Apr 11, 2026, 12:30 AM UTC· resolved Apr 11, 2026, 12:30 AM UTC

1. monitoring Apr 11, 2026, 12:30 AM UTC

   Apr 10, 17:30 PDT Completed - The scheduled maintenance has been completed. Apr 10, 17:00 PDT In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Apr 7, 15:53 PDT Scheduled - Mixpanel will be performing database maintenance on Friday, April 10, from 5:00 PM – 5:30 PM PDT (April 11, 12:00 AM – 12:30 AM UTC). During the maintenance, Mixpanel's Web Application, MCP, Warehouse Connectors, Data Pipelines, Cohort Syncs, GDPR API, Query API, and Raw Export API may be temporarily unavailable. We expect no Ingestion API downtime and no data loss. If requests to MCP, GDPR API, Query API, or Raw Export API fail during the maintenance window, please retry them once the window has concluded. Ongoing Cohort Syncs, Data Pipeline runs, and Warehouse Connector jobs that fail will automatically retry after maintenance is complete. We will post progress updates on our status page. If you have any questions, please contact support.

Read the full incident report →

Started Apr 09, 2026, 09:44 PM UTC· resolved Apr 09, 2026, 09:44 PM UTC

1. monitoring Apr 09, 2026, 09:44 PM UTC

   Apr 9, 14:44 PDT Resolved - This incident has been resolved. Apr 9, 14:00 PDT Monitoring - A fix has been deployed, and all impacted accounts have had their billing re-run. If you continue to receive errors, please ensure the card on file is up to date. If you are still experiencing issues, please submit a support ticket. Apr 9, 13:03 PDT Identified - We are currently experiencing an interruption with our credit card processing. Our engineers have identified the issue and are working on a fix.

Read the full incident report →

Started Mar 16, 2026, 09:47 PM UTC· resolved Mar 16, 2026, 09:47 PM UTC

1. monitoring Mar 16, 2026, 09:47 PM UTC

   Mar 16, 14:47 PDT Resolved - This incident has been resolved. Mar 16, 12:29 PDT Monitoring - A fix has been implemented and we are monitoring the results. Mar 16, 09:50 PDT Identified - Mixpanel is experiencing increased query latency for projects with EU residency, which may result in HTTP 500 responses when querying or saving reports. Projects with US and IN residency remain unaffected. Our engineering team is working on a resolution.

Read the full incident report →

Started Mar 03, 2026, 01:43 AM UTC· resolved Mar 03, 2026, 01:43 AM UTC

1. monitoring Mar 03, 2026, 01:43 AM UTC

   Mar 2, 17:43 PST Resolved - This incident has been resolved. Mar 2, 12:08 PST Update - We have partially mitigated the issue and are continuing to monitor for any further impact. We are also actively working to address the root cause. Mar 2, 11:42 PST Monitoring - A fix has been implemented and we are monitoring the results. Mar 2, 11:39 PST Identified - The issue has been identified and a fix is being implemented. Mar 2, 11:37 PST Investigating - A subset of users are experiencing OAuth issues when connecting to our MCP server. We are currently investigating this issue.

Read the full incident report →

Started Mar 02, 2026, 09:53 PM UTC· resolved Mar 02, 2026, 09:53 PM UTC

1. monitoring Mar 02, 2026, 09:53 PM UTC

   Mar 2, 13:53 PST Resolved - This incident has been resolved. If Mixpanel is still not loading, please clear your cache and cookies. Mar 2, 13:09 PST Monitoring - A fix has been implemented and we are monitoring the results. Mar 2, 13:05 PST Identified - The issue has been identified and a fix is being implemented. Mar 2, 13:00 PST Investigating - We are currently experiencing issues with loading Mixpanel.com and are working to restore service as quickly as possible. Our team is investigating the issue and will provide updates as soon as we have more information. Thank you for your patience.

Read the full incident report →

Started Jan 31, 2026, 02:41 AM UTC· resolved Jan 31, 2026, 02:41 AM UTC

1. monitoring Jan 31, 2026, 02:41 AM UTC

   Jan 30, 18:41 PST Resolved - This incident has been resolved. Jan 30, 17:48 PST Update - Additional fixes have been implemented. We are continuing to monitor for any further issues. Jan 30, 14:14 PST Update - We are continuing to monitor for further issues. We have identified that a subset of Cohort Syncs are still experiencing delays and are working to resolve these remaining cases. Jan 30, 12:05 PST Monitoring - A fix has been implemented, and we are monitoring the results. Recurring cohort syncs should resume on the next scheduled run with no additional action required. Jan 30, 10:39 PST Investigating - We are currently experiencing delays with Cohort Syncs to external destinations, including custom webhooks and engagement platforms. Our team is investigating the issue and actively working on a resolution. We sincerely apologize for the inconvenience and thank you for your kind understanding. If you have any questions, please contact support

Read the full incident report →

Started Jan 21, 2026, 08:48 PM UTC· resolved Jan 21, 2026, 08:48 PM UTC

1. monitoring Jan 21, 2026, 08:48 PM UTC

   Jan 21, 12:48 PST Resolved - This incident has been resolved. Jan 21, 12:27 PST Monitoring - A fix has been implemented and we are monitoring the results. Jan 21, 12:20 PST Investigating - We are currently experiencing issues with loading Mixpanel.com and are working to restore service as quickly as possible. Our team is investigating the issue and will provide updates as soon as we have more information. Thank you for your patience.

Read the full incident report →

Started Dec 09, 2025, 11:55 AM UTC· resolved Dec 09, 2025, 11:55 AM UTC

1. monitoring Dec 09, 2025, 11:55 AM UTC

   Dec 9, 03:55 PST Resolved - This incident has been resolved. Dec 9, 01:05 PST Monitoring - Our Engineering team has identified the issue and deployed a fix - we will continue to review its performance and post another update if any instability reappears or when the problem is fully resolved Dec 9, 00:41 PST Investigating - We are currently experiencing query data discrepancies and are working to restore service as quickly as possible. Our team is investigating the issue and will provide updates as soon as we have more information. Thank you for your patience.

Read the full incident report →

Started Dec 03, 2025, 05:36 PM UTC· resolved Dec 03, 2025, 05:36 PM UTC

1. monitoring Dec 03, 2025, 05:36 PM UTC

   Dec 3, 09:36 PST Resolved - This incident has been resolved. Dec 3, 08:34 PST Monitoring - Earlier today, our SSO authentication broker experienced a service disruption that impacted users attempting to log in to Mixpanel via SSO. During this period, some customers may have encountered intermittent login failures or increased latency during authentication. Okta has implemented mitigations and reports that their services have been restored, though intermittent authentication issues may still occur as the system stabilizes. We are seeing improvement on our end and continue to monitor SSO login performance closely to ensure full recovery for all Mixpanel customers. We will continue to observe authentication behavior and will post another update if any instability reappears or when the issue is fully resolved. Dec 3, 05:54 PST Identified - We are currently experiencing login issues for users authenticating through SSO. This appears to be caused by an ongoing Okta service outage. Our authentication broker (Okta) is experiencing downtime, which prevents successful SSO logins. Okta’s status page: We are currently experiencing login issues for users authenticating through SSO. This appears to be caused by an ongoing Okta service outage. Our authentication broker (Okta) is experiencing downtime, which prevents successful SSO logins. Okta’s status page: https://status.okta.com/#recent

Read the full incident report →

Started Nov 21, 2025, 03:04 AM UTC· resolved Nov 21, 2025, 03:04 AM UTC

1. monitoring Nov 21, 2025, 03:04 AM UTC

   Nov 20, 19:04 PST Resolved - This incident has been resolved. Nov 20, 18:36 PST Monitoring - A fix has been implemented and we are monitoring the results. Nov 20, 17:56 PST Identified - We're experiencing elevated error rates for Query API requests, resulting in HTTP 500 responses for a small subset of users. Our engineering team is working on a resolution.

Read the full incident report →

Started Oct 27, 2025, 03:34 PM UTC· resolved Oct 27, 2025, 03:34 PM UTC

1. monitoring Oct 27, 2025, 03:34 PM UTC

   Oct 27, 08:34 PDT Resolved - This incident has been resolved. Oct 27, 07:22 PDT Monitoring - A fix has been implemented and we are monitoring the results. Oct 27, 07:09 PDT Investigating - We are currently experiencing delays in our data ingestion pipeline, affecting projects enrolled in the EU Residency program. As a result, real-time data for a subset of affected projects is delayed, including those forwarding data from the US to the EU. While no data is being lost, our engineering team is actively investigating the issue and working to restore real-time functionality as quickly as possible. We appreciate your patience as we resolve this matter. If you have any questions, please contact support.

Read the full incident report →

Started Oct 18, 2025, 12:01 AM UTC· resolved Oct 18, 2025, 12:01 AM UTC

1. monitoring Oct 18, 2025, 12:01 AM UTC

   Oct 17, 17:01 PDT Resolved - This incident has been resolved. Oct 17, 15:55 PDT Monitoring - A fix has been implemented and we are monitoring the results. Oct 17, 15:47 PDT Identified - The issue has been identified and a fix is being implemented. Oct 17, 15:24 PDT Update - We are continuing to investigate this issue. Oct 17, 14:34 PDT Investigating - We're experiencing an elevated level of errors loading reports and successfully making calls to our non ingestion APIs. We are currently looking into the issue.

Read the full incident report →