Störungsverlauf von Mixpanel

1. 26. August 2026 um 21:39 UTCinvestigating

   Mixpanel erlebt eine verschlechterte Abfrage-API-Leistung, was zu HTTP 500-Antworten führt, wenn Berichte für Projekte mit US Data Residency abgefragt werden. Projekte mit EU und IN Data Residency bleiben unberührt. Wir schätzen Ihre Geduld, während unsere Ingenieure daran arbeiten, die normale Funktionalität wiederherzustellen. Wir werden Fortschritts-Updates auf unserer Statusseite veröffentlichen. Wenn Sie Fragen haben, wenden Sie sich bitte an den Support.

2. 26. August 2026 um 22:11 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 26. August 2026 um 22:28 UTCmonitoring

   Ein Fix wurde implementiert und wir sehen verbesserte Erfolgsraten für die Query API. Wir werden weiter beobachten, um Stabilität zu gewährleisten.

4. 26. August 2026 um 22:45 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 19. August 2026 um 23:20 UTCidentified

   Wir haben derzeit Probleme mit dem Auffüllen von Ereigniseigenschaften in Dropdown-Menüs. Wir schätzen Ihre Geduld, während unsere Ingenieure daran arbeiten, die Funktionalität wiederherzustellen. Wenn Sie Fragen haben, kontaktieren Sie bitte [email protected]

2. 20. August 2026 um 01:04 UTCidentified

   Wir arbeiten weiter an einer Lösung für dieses Problem.

3. 20. August 2026 um 02:52 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 20. August 2026 um 03:05 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. August 2026 um 07:19 UTCinvestigating

   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. 6. August 2026 um 08:39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 6. August 2026 um 09:12 UTCmonitoring

   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. 6. August 2026 um 13:32 UTCresolved

   This incident has been resolved.

1. 22. Juli 2026 um 08:03 UTCinvestigating

   Wir haben derzeit Probleme mit dem Mixpanel-Agenten in der Webapp. Unser Engineering-Team wurde alarmiert und untersucht das Problem und arbeitet daran, seine Funktionalität wiederherzustellen. Wir schätzen Ihre Geduld, während wir daran arbeiten, diese Angelegenheit zu lösen. Wenn Sie Fragen haben, wenden Sie sich bitte an den Support.

2. 22. Juli 2026 um 09:52 UTCinvestigating

   das Team untersucht weiterhin das Problem und die nächsten Schritte. Danke für deine Geduld.

3. 22. Juli 2026 um 10:55 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 22. Juli 2026 um 14:47 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 11. Juli 2026 um 07:53 UTCinvestigating

   Wir erleben derzeit Verzögerungen in unserer Datenaufnahme-Pipeline, die sich auf Echtzeitdaten für Projekte auswirken, die in den USA registriert sind Projekte, was zu Verzögerungen für eine Teilmenge von Projekten führt. Während keine Daten verloren gehen, untersucht unser Engineering-Team die Angelegenheit aktiv und arbeitet daran, die Echtzeit-Funktionalität so schnell wie möglich wiederherzustellen. Wir schätzen Ihre Geduld in dieser Zeit. Wenn Sie Fragen haben, wenden Sie sich bitte an den Support.

2. 11. Juli 2026 um 09:17 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 11. Juli 2026 um 10:15 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 11. Juli 2026 um 12:54 UTCidentified

   Wir arbeiten weiter an einer Lösung für dieses Problem.

5. 11. Juli 2026 um 14:25 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

6. 11. Juli 2026 um 15:54 UTCresolved

   Dieser Vorfall wurde behoben.

7. 16. Juli 2026 um 23:47 UTCpostmortem

   # Zusammenfassung Zwischen ca. 11:35 Uhr PT am 10. Juli und 7:19 Uhr PT am 11. Juli 2026** lief die Datenaufnahme für Mixpanel-Projekte in der US-Region um bis zu ~2 Stunden zurück. Während dieses Fensters zeigten Berichte und Dashboards vorübergehend unvollständige Daten - aktuelle Zeitbereiche könnten als scharfe, künstliche Tropfen in Metriken wie aktiven Benutzern oder Einnahmen erscheinen. **Es gingen keine Daten verloren.** Alle Ereignisse wurden dauerhaft in die Warteschlange gestellt und vollständig verarbeitet, sobald der Rückstand behoben war; Metriken kehrten von selbst zu genauen Werten zurück, ohne dass Kundenaktionen erforderlich waren. Die Ursache liegt in unseren Einnahmekontrollen: Für eine kleine Anzahl von Projekten mit sehr hohem Volumen waren die von uns erlaubten Einnahmeraten aus der Übereinstimmung mit der für diese Projekte bereitgestellten Kapazität gedriftet. Große historische Importe - völlig legitime Nutzung der Plattform - wurden daher schneller zugelassen, als ihre Infrastruktur aufnehmen konnte, und zwei Eigenschaften unserer Pipeline verwandelten diese lokalisierte Überlastung in eine regionenweite Verzögerung. Die folgenden Fixes richten diese Kontrollen so aus, dass jeder Import jeder Größe automatisch innerhalb sicherer Grenzen gehalten wird. # Was passierte Die Ingestion-Pipeline von Mixpanel ist zersplittert und multi-tenant: Die Daten jedes Projekts werden über eine Reihe von Partitionen verteilt, die für das erwartete Volumen bemessen sind, und für den Durchsatz werden Ereignisse von vielen Kunden in Batches zusammen verarbeitet. Dieses Design liefert eine hohe Effizienz, aber es hängt von einer Invariante ab: Die Rate, mit der wir zugeben, dass der Traffic eines Projekts mit der dafür bereitgestellten Kapazität übereinstimmen muss. Wenn diese Invariante gilt, werden auch sehr große Importe reibungslos absorbiert. Hier hat es nicht gehalten. Eine kleine Anzahl sehr großer historischer Datenimporte lief auf Projekte, deren Aufnahmeraten im Laufe der Zeit weit über ihre bereitgestellte Partitionskapazität hinaus gewachsen waren. Das überschüssige Volumen konzentrierte sich auf bestimmte Partitionen als **hot spots** und sättigte den Teil der Streaming-Flotte, der sie bediente. Zwei Faktoren verbreiterten dann die Auswirkungen: * **Batched, Multi-Tenant Verarbeitung verstärkte die Hot Spots. ** Da Ereignisse von vielen Kunden zusammen in Batches reisen, verzögerten Langsamkeit und Ausfälle auf den überlasteten Partitionen die Ereignisse unabhängiger Kunden, die diese Batches teilten. * **Automatisches Scale-up war ineffektiv.** Das Hinzufügen von Kapazitäten kann einen solchen Hot Spot nicht auflösen, da die überlasteten Partitionen an die gleiche Infrastruktur gebunden bleiben und eine Kapazitätsbegrenzung in einer Komponente unserer Streaming-Infrastruktur verhindert, dass die hinzugefügte Kapazität wirksam wird. Zusammen verwandelten diese eine kurze, selbstheilende Verlangsamung in eine mehrstündige Verzögerung, die manuelle Eingriffe erforderte. # Timeline \(Pacific Time, 10-11 Juli \) * ** 11:35 Uhr ** - Automatisierte Alarmierung erkannte den Einnahmerückstand; Bereitschaftsingenieur sofort eingestellt. * **12:49 Uhr - Statusseite Vorfall veröffentlicht; Auswirkungen auf die US-Region nur. * **1:23 AM** — Der größte beitragende Import wurde angehalten. * **1:55–6:48 Uhr – Progressive Minderungsmaßnahmen: zusätzliche Traffic-Quellen gedrosselt, bestimmte Daten, die mit Zustimmung des Kunden zurückgehalten wurden, Fehlerisolierung in der Pipeline aktiviert und betroffene Infrastrukturknoten ersetzt. * **7:19 Uhr - Backlog vollständig verarbeitet; alle Projekte aktuell. Die Statusseite wurde zur Überwachung verschoben und dann nach einem stabilen Beobachtungszeitraum aufgelöst. # Wurzelursache 1. **Ingestion Rate Limits falsch ausgerichtet mit Provisioned Kapazität. ** Für die Fahrprojekte waren die Preise, die unsere Plattform zugegeben hatte, nicht mit der für sie bereitgestellten Infrastruktur vergleichbar, so dass legitime Großimporte schneller hereingelassen wurden, als ihre Partitionen absorbieren konnten. Das ist die systemische Ursache. Die Einfuhren selbst waren eine legitime Nutzung der Plattform. 2. **Batched, Multi-Tenant Verarbeitung verstärkte die Überlastung. ** Fehler auf den überlasteten Partitionen verzögerten die Ereignisse unabhängiger Kunden, die die gleichen Verarbeitungschargen teilten, und verteilten ein lokalisiertes Problem auf der Plattform. 3. ** Traffic zu den überlasteten Partitionen konnte nicht neu verteilt werden.** Die Partition-zu-Server-Zuordnung in der Streaming-Schicht war nicht lastbewusst, so dass die Hot Spots unabhängig von der Flottengröße an die gleichen Server gepinnt blieben - die Gesamtkapazität war ausreichend, konnte aber nicht genutzt werden. Eine Skalierungsgrenze in einer Komponente unserer Streaming-Infrastruktur verschärfte dies, indem sie verhinderte, dass das Skalieren von Kapazitäten hinzugefügt wurde, was die Diagnose verzögerte, bis Ingenieure manuell eingriffen. # Was wir verändern Der Endzustand, auf den wir hinarbeiten: **Die Einnahmegrenzen jedes Projekts passen automatisch zu seiner bereitgestellten Kapazität, so dass Importe jeder Größe, einschließlich vollständiger historischer Backfills und Data Warehouse-Syncs, ohne vorherige Koordination laufen können und das Volumen eines Projekts verhindert wird, dass die Datenfrische eines anderen beeinflusst wird. **. Bereits eingesetzt — Verbesserung unserer Einnahmehandhabung: * **Verbessertes Hot-Spot-Handling.** Die Verkehrsverteilung in der Streaming-Schicht ist jetzt lastbewusst und verteilt die konzentrierte Last gleichmäßiger über die Flotte, und einzelne Problemelemente werden jetzt separat getestet, anstatt den Rest ihrer Charge zu halten - was die Auswirkungen einer lokalisierten Überlast auf den nicht zusammenhängenden Verkehr reduziert, wenn auch nicht eliminiert. * **Re-provisioned the most-volume workloads** auf entsprechend dimensionierte Infrastruktur, priorisiert nach Risiko. Bereits bereitgestellt – Änderung der Art und Weise, wie wir den Streaming-Service von Drittanbietern betreiben: * **Auditiert und neu abgestimmt das Kapazitätsprofil der Flotte **, so dass einzelne Server wesentlich mehr Spielraum für konzentrierte Last haben, und arbeitete mit dem Anbieter, um die Skalierungsbeschränkung während des Vorfalls zu beheben. Im Gange: * **Kapazitätsbewusste Ratenbegrenzung** - Schließung der Lücken zwischen individuell gewährten Projektratenbegrenzungen und der tatsächlichen bereitgestellten Kapazität jedes Projekts, Ausweitung der Ratenbegrenzung auf Einnahmepfade, denen es zuvor fehlte, und Kopplung einer zukünftigen Limiterhöhung mit einer Kapazitätserhöhung, die verhindern soll, dass sich diese Klasse von Fehlausrichtungen wiederholt. * **Finer-grained Volumenüberwachung und Alarmierung ** so Kapazitätsfehlausrichtung wird erkannt und korrigiert, bevor es einen Kunden betreffen kann. * Bewertung einer stärkeren Priorisierung der Workload-Isolation / Backlog-Wiederherstellung für Massen- / Backfill-Verkehrspfade, so dass historische Importe die Auswirkungen auf den Live-Verkehr reduziert haben # Gemeinsame Fragen * **Wurden Daten verloren?** Die Ereignisse standen während des gesamten Vorfalls dauerhaft in der Warteschlange und wurden nach Löschung des Rückstands vollständig verarbeitet. Alle metrischen Tropfen, die während des Fensters gesehen wurden, waren ein Anzeigeartefakt der Verzögerung und wurden selbst korrigiert. * **Muss ich große Importe oder Backfills mit Mixpanel koordinieren?** Nein — Unser Ziel ist es, dass die Plattform jeden Import automatisch innerhalb sicherer Raten hält, so dass Backfills und Lagersynchronisierungen ohne Planung oder Ankündigung ausgeführt werden können. Wir führen immer noch die kapazitätsbewussten Kontrollen aus, die dies ermöglichen. Wenn Sie in der Zwischenzeit einen ungewöhnlich großen Import oder eine Auffüllung planen, empfehlen wir Ihnen, sich mit Ihrem Kontoteam zu koordinieren, damit wir die Kapazität im Voraus bestätigen können. * **Wie wird das verhindert?** Die systemische Lösung schließt die Lücken zwischen individuell gewährten Projektratenlimits und der tatsächlichen bereitgestellten Kapazität jedes Projekts und erweitert die Ratenbegrenzung auf die Einnahmepfade, denen es zuvor fehlte - so dass eine Überlastung dieser Art bei der Zulassung gestoppt wird. Darüber hinaus ist die Skalierungsbeschränkung, die den Vorfall verlängert hat, behoben, die Pipeline versucht nun einzelne Problemelemente separat, so dass eine lokalisierte Überlastung weit weniger Auswirkungen auf den nicht zusammenhängenden Datenverkehr hat und der Massenverkehr weiter vom Live-Datenverkehr isoliert wird. * **Können einzelne Projekte während der Wiederherstellung priorisiert werden?** Diese Fähigkeit bestand während des Vorfalls nicht — alle Projekte erholten sich mit der gleichen Rate. Wir evaluieren Priorisierungsmechanismen für die Rückstauung im Rahmen unserer Folgearbeit. Wir entschuldigen uns für die Störung und für die Besorgnis, die die vorübergehend depressiven Metriken verursacht haben. Bitte kontaktieren Sie Ihr Account-Team oder unterstützen Sie bei Fragen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. Juni 2026 um 19:47 UTCinvestigating

   Mixpanel erlebt eine verschlechterte Leistung mit unserer Query API, einschließlich erhöhter Latenz. Möglicherweise sehen Sie langsam ladende Berichte oder Abfragefehler. Wir schätzen Ihre Geduld, während unsere Ingenieure daran arbeiten, die normale Funktionalität wiederherzustellen. Wir werden Fortschritts-Updates auf unserer Statusseite veröffentlichen. Wenn Sie Fragen haben, wenden Sie sich bitte an den Support.

2. 29. Juni 2026 um 21:04 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 29. Juni 2026 um 22:42 UTCidentified

   Die Abfragelatenz hat sich stabilisiert, obwohl unser Team weiterhin die zugrunde liegende Ursache der verschlechterten Leistung untersucht. Wir werden weiterhin Updates veröffentlichen, während unsere Untersuchung fortschreitet. Vielen Dank für Ihre Geduld.

4. 30. Juni 2026 um 02:15 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 30. Juni 2026 um 03:30 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 3. Juni 2026 um 20:05 UTCinvestigating

   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. 3. Juni 2026 um 20:17 UTCidentified

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

3. 3. Juni 2026 um 21:27 UTCresolved

   This incident has been resolved.

1. 2. Juni 2026 um 11:02 UTCinvestigating

   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. 2. Juni 2026 um 12:31 UTCidentified

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

3. 2. Juni 2026 um 14:31 UTCmonitoring

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

4. 2. Juni 2026 um 16:53 UTCresolved

   This incident has been resolved.

1. 1. Juni 2026 um 14:15 UTCinvestigating

   We are experiencing delays with our data ingestion and shuffling pipeline to projects with US & India data residency. 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. 1. Juni 2026 um 15:08 UTCinvestigating

   We have now identified an ingestion delay for EU projects, and are continuing to investigate the issue. Thank you for your patience.

3. 1. Juni 2026 um 15:29 UTCidentified

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

4. 1. Juni 2026 um 16:38 UTCmonitoring

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

5. 1. Juni 2026 um 19:42 UTCresolved

   This incident has been resolved.

1. 19. Mai 2026 um 19:03 UTCinvestigating

   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. 19. Mai 2026 um 19:10 UTCidentified

   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. 19. Mai 2026 um 20:23 UTCmonitoring

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

4. 19. Mai 2026 um 21:18 UTCresolved

   This incident has been resolved.

1. 14. Mai 2026 um 23:17 UTCinvestigating

   We are experiencing degraded performance with our Query API, including increased latency. You may see slow-loading reports, 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. 14. Mai 2026 um 23:48 UTCidentified

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

3. 15. Mai 2026 um 10:19 UTCidentified

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

4. 15. Mai 2026 um 12:28 UTCidentified

   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.

5. 15. Mai 2026 um 14:31 UTCidentified

   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.

6. 15. Mai 2026 um 16:37 UTCidentified

   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.

7. 15. Mai 2026 um 18:47 UTCidentified

   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.

8. 15. Mai 2026 um 19:56 UTCidentified

   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.

9. 15. Mai 2026 um 21:23 UTCidentified

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

10. 15. Mai 2026 um 22:14 UTCidentified

    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.

11. 16. Mai 2026 um 00:17 UTCidentified

    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.

12. 16. Mai 2026 um 01:52 UTCmonitoring

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

13. 16. Mai 2026 um 02:50 UTCresolved

    This incident has been resolved.

14. 21. Mai 2026 um 21:43 UTCpostmortem

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

1. 13. Mai 2026 um 16:34 UTCidentified

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

2. 13. Mai 2026 um 21:40 UTCidentified

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

3. 14. Mai 2026 um 13:35 UTCresolved

   This incident has been resolved.

1. 12. Mai 2026 um 17:45 UTCinvestigating

   We are currently investigating an issue that leads to degraded performance of Data Volume Monitoring in a subset of US-based projects. We truly appreciate your patience and apologize for the inconvenience. If you have any questions, please contact support (https://mixpanel.com/get-support).

2. 12. Mai 2026 um 17:46 UTCidentified

   An upstream service provider outage is causing this issue. We are deploying a fix to mitigate the disruption.

3. 12. Mai 2026 um 20:24 UTCmonitoring

   A fix has been implemented, and we are monitoring the result.

4. 12. Mai 2026 um 21:44 UTCresolved

   This incident has been resolved.

1. 6. Mai 2026 um 00:00 UTCinvestigating

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

2. 6. Mai 2026 um 09:32 UTCidentified

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

3. 6. Mai 2026 um 20:04 UTCresolved

   This incident has been resolved.

1. 9. April 2026 um 20:03 UTCidentified

   We are currently experiencing an interruption with our credit card processing. Our engineers have identified the issue and are working on a fix.

2. 9. April 2026 um 21:00 UTCmonitoring

   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.

3. 9. April 2026 um 21:44 UTCresolved

   This incident has been resolved.

1. 16. März 2026 um 16:50 UTCidentified

   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.

2. 16. März 2026 um 19:29 UTCmonitoring

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

3. 16. März 2026 um 21:47 UTCresolved

   This incident has been resolved.

1. 2. März 2026 um 21:00 UTCinvestigating

   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.

2. 2. März 2026 um 21:09 UTCidentified

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

3. 2. März 2026 um 21:09 UTCmonitoring

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

4. 2. März 2026 um 21:53 UTCresolved

   This incident has been resolved. If Mixpanel is still not loading, please clear your cache and cookies.

1. 2. März 2026 um 19:48 UTCinvestigating

   A subset of users are experiencing OAuth issues when connecting to our MCP server. We are currently investigating this issue.

2. 2. März 2026 um 19:49 UTCidentified

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

3. 2. März 2026 um 19:50 UTCmonitoring

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

4. 2. März 2026 um 20:08 UTCmonitoring

   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.

5. 3. März 2026 um 01:43 UTCresolved

   This incident has been resolved.

1. 2. März 2026 um 18:41 UTCinvestigating

   A subset of users are experiencing OAuth issues when connecting to our MCP server. We are currently investigating this issue.

2. 2. März 2026 um 18:44 UTCidentified

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

3. 2. März 2026 um 18:45 UTCmonitoring

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

4. 2. März 2026 um 18:53 UTCresolved

   This incident is resolved.

1. 30. Januar 2026 um 18:39 UTCinvestigating

   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

2. 30. Januar 2026 um 20:05 UTCmonitoring

   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.

3. 30. Januar 2026 um 22:14 UTCmonitoring

   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.

4. 31. Januar 2026 um 01:48 UTCmonitoring

   Additional fixes have been implemented. We are continuing to monitor for any further issues.

5. 31. Januar 2026 um 02:41 UTCresolved

   This incident has been resolved.