Störungsverlauf von Mixpanel

1. 21. Oktober 2026 um 18:04 UTCmonitoring

   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. 21. Oktober 2026 um 20:15 UTCresolved

   This incident has been resolved.

1. 21. Oktober 2026 um 22:28 UTCmonitoring

   Wir haben Berichte erhalten, dass Anfragen an decision.mixpanel.com fehlschlagen. Jeder Datenverkehr, der über decide.mixpanel.com gesendet wird, kann betroffen sein, einschließlich Feature-Flags und Event-Tracking. Um den Service jetzt wiederherzustellen, stellen Sie Anfragen an api.mixpanel.com (USA), api-eu.mixpanel.com (EU) oder api-in.mixpanel.com (IN), abhängig von der Datenresidenz Ihres Projekts. Wir haben eine Abschwächung eingeführt und überwachen die Ergebnisse. Wir sehen den Verkehr wiederhergestellt. Wir werden Fortschritts-Updates auf unserer Statusseite veröffentlichen. Wenn Sie Fragen haben, wenden Sie sich bitte an den Support.

2. 22. Oktober 2026 um 01:34 UTCresolved

   Dieser Vorfall wurde behoben.

3. 24. Oktober 2026 um 01:58 UTCpostmortem

   # **Mixpanel RCA: Anfragen an** [**decide.mixpanel.com**](http://decide.mixpanel.com) **Failed, 15.–21. Oktober 2026** ### **Zusammenfassung ** Vom 15. Oktober 2026 bis zum 21. Oktober 2026 waren Anfragen an `decide.mixpanel.com` und `api-decide.mixpanel.com` fehlgeschlagen. Dies betraf Kunden, die Ereignisverfolgung, Profilaktualisierungen oder Feature-Flag-Anfragen an diesen Hostnamen gesendet haben, normalerweise über einen Proxy. Ereignisse, die während dieses Fensters an diese Domain gesendet wurden, wurden von Mixpanel nicht empfangen und diese Daten können von Mixpanel nicht wiederhergestellt werden. **Verkehr gesendet zu ** `api.mixpanel.com`, ** `api-js.mixpanel.com`, `api-eu.mixpanel.com` und ** `api-in.mixpanel.com` ** waren nicht betroffen. ** Der Dienst für diesen Hostnamen war unbeabsichtigt betroffen, während wir die Endpunktinfrastruktur "/entscheiden" entfernten. Die Hostnamen wurden aufgrund eines falschen Verständnisses der Systemabhängigkeiten als Teil des Endpunkts behandelt. Um diese Klasse von Problemen zu vermeiden, fügen wir Verkehrsüberwachung für die Hostnamen "decide.mixpanel.com" und "api-decide.mixpanel.com" hinzu. Wir benötigen auch einen bestätigten Null-Traffic auf Hostname-Ebene, bevor ein Hostname entfernt wird. ** Wir haben seitdem den Service auf** `decide.mixpanel.com` wiederhergestellt. ### **Was ist passiert ** Ältere Mixpanel-SDKs nannten den `/decide`-Endpunkt zum Abrufen der Konfiguration für [**Legacy Automatically Tracked Mobile Events**](https://docs.mixpanel.com/docs/tracking-methods/sdks/ios#legacy-automatically-tracked-events). Wir haben [den Ruhestand des Endpunktes angekündigt] (https://docs.mixpanel.com/changelogs#2026-01-26), und seit einiger Zeit hat `/decide` eine `410` Antwort zurückgegeben. Separat handelten `decide.mixpanel.com` und `api-decide.mixpanel.com` als Aliase für unsere Standard-API-Hostnamen. Zum Beispiel hat `decide.mixpanel.com/track` Ereignisse genauso aufgenommen wie `api-js.mixpanel.com/track`. Einige Kunden hatten Proxys oder SDK-Konfigurationen eingerichtet, um ihren Traffic an diese Hostnamen zu senden. Am 15. Oktober um 19:40 Uhr CDT, während der endgültigen Bereinigung des `/decide`-Endpunkts, entfernten wir die DNS-Einträge für `decide.mixpanel.com` und `api-decide.mixpanel.com` und entfernten beide Hostnamen aus unserem Load Balancer. Bevor wir die Änderung vornahmen, bestätigten wir, dass der Traffic zum `/decide`-Endpunkt auf Null gesunken war. Unser Monitoring maß jedoch den Traffic nach Endpunkt und nicht nach Hostname. Es zeigte sich daher nicht, dass andere Anfragen, wie `/track` und `/flags`, Mixpanel immer noch über diese Hostnamen erreichten. Von da an sind alle Anfragen an diesen Hostnamen fehlgeschlagen, einschließlich Endpunkte wie `/track`, `/engage`, `/groups` und `/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 that we don’t have a copy to restore. Wenn Sie diese Daten an anderer Stelle gespeichert haben, z. B. in Proxy-Protokollen oder Ihrem Data Warehouse, können Sie sie erneut an die Ingestion APIs [/import](https://docs.mixpanel.com/reference/import-events), [/engage,](https://docs.mixpanel.com/reference/profile-set) und [/groups](https://docs.mixpanel.com/reference/group-set-property) senden. * **Feature Flags:** Feature-Flag-Anfragen, die an diese Hostnamen gesendet wurden, sind fehlgeschlagen. SDKs dienten der zuletzt gespeicherten Variante, falls vorhanden, oder anderweitig dem in Ihrem Code konfigurierten Fallback-Wert. ### Timeline \(Zentralzeit, Oktober 2026\) * **Oktober 15, 19:40 Uhr CDT:** Die Entfernung des Hostnamens wird angewendet. Anfragen an `decide.mixpanel.com` und `api-decide.mixpanel.com` beginnen zu scheitern. * **Oktober 16, 5:22 Uhr CDT:** Wir erhalten den ersten Kundenbericht. Es wird zunächst verstanden, dass es sich um den geplanten "/entscheidenden" Ruhestand handelt. * **Oktober 21, 11:42 Uhr CDT:** Nach einer Zunahme von Kundenberichten über fehlgeschlagenes Tracking für Proxys identifizieren wir die Entfernung des Hostnamens als Ursache. * **Oktober 21, 12:26 Uhr CDT:** Wir stellen die Hostnamen wieder her. "/entscheiden" bleibt im Ruhestand. * **Oktober 21, 1:51 PM CDT:** Wir bestätigen, dass der Traffic zu den wiederhergestellten Hostnamen wiederhergestellt wurde. * **Oktober 21, 8:34 Uhr CDT:** Der Vorfall ist gelöst. ### **Wurzelursache** 1. Während des "/entscheiden" Ruhestandes wurden "decide.mixpanel.com" und "api-decide.mixpanel.com" unbeabsichtigt entfernt. 2. Diese Hostnamen wurden so konfiguriert, dass sie den gesamten API-Datenverkehr akzeptieren, nicht nur `/decide`-Anforderungen, und dieses Verhalten war nicht dokumentiert. 3. Unser Monitoring verfolgte den Traffic zum `/decide`-Endpunkt, aber nicht zu diesen Hostnamen, so dass Vorwechselprüfungen nicht zeigten, dass anderer Traffic noch aktiv war. 4. Da die Hostnamen und der pensionierte Endpunkt einen gemeinsamen Namen haben, wurden frühe Kundenberichte zunächst als erwartete Auswirkungen des angekündigten "/entscheidenden" Ruhestands interpretiert. Dies verzögerte die Eskalation. ### **Was wir verändern** * **Überwachung und Alarmierung:** Wir fügen Traffic- und Fehlerratenüberwachung und Alarmierung für "decide.mixpanel.com" und "api-decide.mixpanel.com" hinzu, so dass Fehler automatisch und nicht durch Kundenberichte erkannt werden. * **Hostname Audit:** Wir prüfen alle öffentlichen API-Hostnamen und Routing-Aliase für ähnliche undokumentierte Einstiegspunkte und werden neue Hostnamen und Aliase überprüfen, bevor sie live gehen. Wir verfolgen auch den Traffic, der mit einem unerwarteten Hostnamen eintrifft. * **Sichere Entfernungen:** Vor jeder zukünftigen Änderung eines öffentlichen Hostnamens werden wir Null-Traffic auf Hostnamen-Ebene bestätigen und alle Projekte identifizieren und kontaktieren, die ihn noch verwenden. * **Kundenkommunikation:** Wir werden Kunden im Voraus über wesentliche Infrastrukturänderungen informieren, die sich auf öffentliche Hostnamen auswirken, einschließlich der Veröffentlichung auf einer Zeitleiste in unserem Changelog. **Bereits eingesetzt:** Restauriert `decide.mixpanel.com` und `api-decide.mixpanel.com` "/entscheiden" bleibt im Ruhestand #### **Allgemeine Fragen** * **Waren meine Daten betroffen?** Nur wenn Ihr SDK oder Proxy zwischen dem 15. Oktober und dem 21. Oktober Anfragen an `decide.mixpanel.com` oder `api-decide.mixpanel.com` gesendet hat. Daten, die während dieses Fensters gesendet wurden, wurden nicht empfangen und können von Mixpanel nicht wiederhergestellt werden. Wenn Sie eine Kopie dieser Daten gespeichert haben, können Sie diese erneut an Mixpanel senden, indem Sie unsere Ingestion-API-Endpunkte wie `/import` für Ereignisse verwenden. * **Muss ich etwas ändern?** Nein, die Domains funktionieren wieder. Wir empfehlen die Verwendung von `api.mixpanel.com` \(oder `api-eu.mixpanel.com` / `api-in.mixpanel.com` für die Datenresidenz in der EU und Indien) als API-Domain. * ** Kommt '/entscheiden' zurück? Nein. Es bleibt wie angekündigt im Ruhestand und ist vom Hostnamen "decide.mixpanel.com" getrennt. Es tut uns leid für die Störung. Wenn Sie Fragen zu Ihrem Projekt haben, wenden Sie sich bitte an Ihr Account-Team oder den Mixpanel-Support.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 16:32 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. 8. Oktober 2026 um 17:32 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 8. Oktober 2026 um 18:31 UTCidentified

   Wir haben die Ursache der Einnahmeverzögerung als ein Upstream-Problem mit unserem Cloud-Speicheranbieter Google Cloud identifiziert, das sich auf eine Teilmenge von US-Projekten auswirkt. Google hat dies als ein Problem mit hoher Priorität an ihrem Ende bestätigt, aber noch keine ETA bereitgestellt. Wir haben Abschwächungen eingesetzt, um eine reibungslose Erholung zu gewährleisten, sobald sie sich auflöst. Es gehen keine Ereignisse verloren. Dies ist streng genommen eine Verzögerung bei der Einnahme, alle betroffenen Daten werden weiterhin neu verarbeitet, sobald das Problem behoben ist.

4. 8. Oktober 2026 um 19:30 UTCmonitoring

   Unsere Metriken zeigen, dass die Einnahme aufgeholt wird und keine Verzögerung mehr auftritt. Google hat die Lösung des zugrunde liegenden Upstream-Problems noch nicht bestätigt, so dass wir im Falle eines Wiederauftretens weiterhin genau beobachten.

5. 8. Oktober 2026 um 21:30 UTCmonitoring

   Keine Änderung seit unserem letzten Update, wir beobachten weiterhin keine aktive Einnahmeverzögerung an unserem Ende, und alle Systeme bleiben gesund. Wir beobachten weiterhin genau.

6. 8. Oktober 2026 um 22:30 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

7. 8. Oktober 2026 um 23:30 UTCmonitoring

   Die Systeme sind stabil geblieben, ohne dass die Einnahmeverzögerung erneut auftritt. Wir behalten die Dinge im Auge, während wir auf die endgültige Bestätigung unseres Upstream-Anbieters warten.

8. 9. Oktober 2026 um 00:22 UTCresolved

   Dieser Vorfall wurde behoben. Das Upstream-Problem mit unserem Cloud-Speicheranbieter wurde behoben, und unsere Ingestion-Pipeline funktioniert normal ohne aktive Verzögerungen. Während dieses Vorfalls gingen keine Ereignisse verloren, alle betroffenen Daten wurden vollständig aufbereitet. Vielen Dank für Ihre Geduld während dieses Vorfalls.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

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.

5. 8. September 2026 um 18:25 UTCpostmortem

   # Mixpanel RCA: Unterbrechung des temporären Abfragedienstes für US-Projekte 26. August 2026 # Zusammenfassung Zwischen ca. 14:02 Uhr und 15:19 Uhr PT am 26. August 2026** wurden bei Projekten in der US-Region Fehler beim Laden von Berichten und beim Ausführen von Abfragen über die Mixpanel-Benutzeroberfläche und die Abfrage-API festgestellt. Während dieses Fensters sind einige Abfragen in der Region fehlgeschlagen oder haben Fehler zurückgegeben. **Es gingen keine Kundendaten verloren und die Datenaufnahme war nicht betroffen.** Alle Ereignisse wurden während des gesamten Vorfalls normal gesammelt und gespeichert; Sobald der Abfragedienst wiederhergestellt wurde, spiegelten alle Berichte vollständige, genaue Daten wider, ohne dass eine Kundenaktion erforderlich war. Die Ursache wurde als kürzlich eingesetztes internes Tool für die Wiederholung von Diagnoseabfragen identifiziert, eine Fähigkeit, mit der unsere Ingenieure Kopien vergangener Abfragen erneut auf die Debug-Performance ausführen können, die unerwartet große Datenmengen auf die Festplatten unserer Abfrageserver schrieb und Speicherkapazität verbrauchte, die die Server zum Betrieb benötigen. Als diese Festplatten gefüllt waren, nahmen sich die betroffenen Server selbst aus dem Dienst. Der Service wurde wiederhergestellt, die betroffenen Server wurden wieder online gestellt und das interne Tooling wurde deaktiviert. Die unten aufgeführten Korrekturen fügen Speichersicherheiten hinzu, um die Fähigkeit der internen Tools, Ressourcen auf Abfrageservern zu verbrauchen, zu entfernen, und sollen verhindern, dass diese Klasse von Fehlern in Zukunft erneut auftritt. # Was passierte Die Abfrage-Engine von Mixpanel läuft auf einer Flotte von Servern, die jeweils einen Satz lokaler Speichervolumen verwenden, um die Daten zwischenzuspeichern, die für die schnelle Beantwortung von Anfragen erforderlich sind. Unabhängig davon verwenden unsere Ingenieure Diagnoseabfrage-Replay-Tools, eine Fähigkeit, mit der unsere Ingenieure die Abfrageleistung reproduzieren und debuggen. Während der Anwendung der Diagnose-Abfrage-Wiedergabe-Tools auf eine große, komplexe Abfrage führte ein Softwarefehler dazu, dass die Abfrage-Wiedergabe-Erfassungen über die gesamte Flotte aufgefächert wurden, anstatt auf einen einzigen Server beschränkt zu bleiben. Darüber hinaus verursachte es weit mehr Daten, als ohne rechtzeitige Räumung auf einem einzigen Server gespeichert werden sollten. Zwei Faktoren erweiterten dann die Auswirkungen des Problems: * Ein einziges volles Speichervolumen hat einen Server vollständig außer Betrieb genommen. Jeder Server behandelt seinen Cache als ungesund, wenn eines seiner Speichervolumen einen Nutzungsschwellenwert überschreitet, selbst wenn alle anderen Volumes gesund sind. Die replay-daten wurden auf einem bestimmten volumen auf jedem server geschrieben, so dass server in der region ihre gesundheitskontrollen fast gleichzeitig nicht bestanden. * Die Bereinigungslimits berücksichtigten nicht die Datengröße. Die Sicherheitsvorkehrung, die die Wiedergabedaten auf Festplatten einschränkt, zählte Elemente auf Anwendungsebene anstelle von Bytes auf Dateisystemebene, so dass eine kleine Anzahl unerwartet großer Captures den Scheck bestanden hat, während sie den größten Teil der Kapazität des Volumens verbrauchten. Zusammengenommen ermöglichten diese einen einzigen Debugging-Workflow, der normalerweise einen vernachlässigbaren Footprint hat, um die Produktionsabfrage in der gesamten US-Region zu unterbrechen. # Timeline \(Pacific Time, 26. August 2026\) * ** 14:00 Uhr * - Erste übergroße Diagnosewiedergabe wurde geschrieben; Speichervolumen begannen ihre Kapazität zu erreichen und die Erfolgsrate bei Abfragen begann kurz danach zu sinken. * **2:17 Uhr * - Automatisierte Alarmierung hat den Bereitschaftstechniker auf die Seite gebracht; die Untersuchung begann sofort und weitere Ingenieure wurden eingestellt. * **2:39 Uhr ** - Statusseite Vorfall veröffentlicht; In-App-Banner um 14:40 Uhr angezeigt. * **2:53 Uhr ** - Ursache identifiziert; Wiederherstellungsbemühungen begannen auf der ersten betroffenen Servergruppe. * **3:19 Uhr ** - Der Abfragedienst wurde für die überwiegende Mehrheit des Datenverkehrs wiederhergestellt; die endgültige Servergruppe wurde um 15:27 Uhr vollständig wiederhergestellt. * **3:45 Uhr** — Der Vorfall wurde nach einem stabilen Beobachtungszeitraum behoben. Das diagnostische Replay-Tooling, das das Problem auslöste, wurde am selben Abend vollständig deaktiviert. # Wurzelursache 1. ** Ein Softwarefehler in unserem Abfrage-Replay-Tooling verursacht unbegrenzte Schreibvorgänge in den Produktionsspeicher. ** Eine kürzlich eingesetzte Fähigkeit zum Reproduzieren von Abfragen hat eine bestimmte Klasse komplexer Abfragen falsch gehandhabt, was dazu führte, dass sich die Erfassungen auf jeden Abfrageserver in der Region ausbreiteten und weit mehr Daten in die betroffenen Volumes schrieben, als das Design angenommen hatte. 2. **Wiedergabedateien verbrauchten Festplattenkapazität, von der die Abfragebedienung abhängt. ** Das Replay-Tooling schrieb seine Dateien auf die lokalen Festplatten der Abfrageserver, so dass die auslaufenden Replay-Daten die Speicherkapazität erschöpften, die die Server benötigen, um Anfragen zu beantworten. 3. **Sicherheitskräfte haben das Verhalten nur teilweise berücksichtigt. ** Die Bereinigungsrichtlinie für diagnostische Wiedergabedaten beschränkte die Anzahl der Elemente auf der Festplatte, aber nicht ihre Gesamtgröße, so dass sie nicht aktiviert wurde. Alarmierung auf Speichervolumen markierte das Wachstum, wurde aber nicht als kritisch pro Server-Basis eskaliert, was die Erkennung verzögerte, bis Abfragefehler begannen. # Was wir verändern Der Endzustand, auf den wir hinarbeiten: interne Diagnoseabfrage-Wiedergabedaten, die im dedizierten Objektspeicher gespeichert sind, wodurch die Produktionsabfrageserver nicht belastet werden. Bereits eingesetzt: * ** Das interne Tooling, das den Vorfall verursacht hat, wurde deaktiviert und das zugrunde liegende Problem behoben, sodass die Diagnoseerfassungen auf einen einzigen Server beschränkt sind und die spezifische Abfrageklasse korrekt behandelt wird. * **Dokumentierte das während des Vorfalls verwendete gezielte Wiederherstellungsverfahren **, d.h. das Löschen nur des betroffenen Speichervolumens, anstatt vollständige Servergruppen neu zu starten, in unseren operativen Runbooks, wodurch die Wiederherstellungszeit verkürzt wird, wenn die Kapazität eines Volumens in Zukunft erschöpft ist. Im Gange: * **Filesystem-Ebene, größenbasierte Grenzen für diagnostische Wiedergabedaten **, Begrenzung von Gesamtbytes auf der Festplatte anstelle von Item Counts, so dass übergroße Captures abgelehnt oder vertrieben werden, bevor sie die Kapazität des Volumes beeinflussen können. * ** Strengere Speicheralarmierung**, eskalierende Volumensättigung pro Server als kritisch, bevor sie die Abfrage-Gesundheitsüberprüfungen beeinflussen kann. * ** Verschieben von Abfragewiedergabedaten in einen dedizierten Objektspeicher**, so dass keine Ressourcen auf Produktionsabfrageservern verbraucht werden. # Gemeinsame Fragen * **Wurden Daten verloren?** Die Datenaufnahme blieb während des gesamten Vorfalls unberührt: Ereignisse wurden weiterhin gesammelt, in die Warteschlange gestellt und normal gespeichert. Lediglich die Abfragefähigkeit wurde unterbrochen. Sobald der Dienst wiederhergestellt wurde, spiegelten alle Berichte vollständige Daten wider. * **Waren gespeicherte Berichte, Dashboards oder Projekteinstellungen betroffen?** Nein. Der Vorfall betraf nur die Abfrageausführung. Nichts, was in Ihrem Projekt gespeichert ist, hat sich geändert. * **Warum hat es mehrere US-Projekte gleichzeitig beeinflusst?** Die übergroßen Diagnosewiedergabedaten, die fast gleichzeitig auf die Festplatten jedes Abfrageservers geschrieben werden, und jeder Server entfernt sich selbst aus dem Dienst, wenn ein Volume gefüllt wird. Das Verhindern, dass interne Tools Query-Server-Speicher verbrauchen, ist ein zentraler Bestandteil unserer Sanierungsarbeit. * **Wie wird das verhindert?** Das Werkzeugproblem ist behoben und das Werkzeug bleibt deaktiviert, bis größenbasierte Grenzen vorhanden sind. Die Speicheralarmierung wird verschärft, so dass die Sättigung abgefangen wird, bevor sie die Abfragebedienung beeinflusst. Strukturell verschieben wir Diagnosedaten vollständig von den Produktionsabfrageservern, so dass interne Debugging-Daten keinen Speicherplatz auf den Servern verbrauchen, die für die Abfrageverarbeitung verantwortlich sind. Wir entschuldigen uns für die Störung und für die Zeitberichte waren nicht verfügbar. Bitte kontaktieren Sie Ihr Account-Team oder unterstützen Sie bei Fragen.

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.