Historia awarii Mixpanel

1. 21 października 2026 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 października 2026 20:15 UTCresolved

   This incident has been resolved.

1. 21 października 2026 22:28 UTCmonitoring

   Otrzymaliśmy raporty, że prośby do decide.mixpanel.com zawodzą. Każdy ruch wysyłany przez decide.mixpanel.com może mieć wpływ, w tym flagi funkcji i śledzenia zdarzeń. Aby przywrócić usługę teraz, wskaż żądania do api.mixpanel.com (US), api- eu.mixpanel.com (EU) lub api- in.mixpanel.com (IN), w zależności od pozostałości danych projektu. Wywołaliśmy złagodzenie i monitorujemy wyniki. Widzimy przywrócony ruch. Umieścimy aktualizacje postępu na naszej stronie statusu. Jeśli masz jakieś pytania, skontaktuj się ze wsparciem.

2. 22 października 2026 01:34 UTCresolved

   Ten incydent został rozwiązany.

3. 24 października 2026 01:58 UTCpostmortem

   * * * Mixpanel RCA: Requests to * * [* * decide.mixpanel.com * *] (http: / / decide.mixpanel.com) * * Failed, October 15- 21, 2026 * * / Podsumowanie Od 15 października 2026 do 21 października 2026, prośby wysłane do 'decide.mixpanel.com' i 'api- decide.mixpanel.com' nie powiodły się. To miało wpływ na klientów, którzy wysyłali śledzenie zdarzeń, aktualizacje profilu lub żądania flagi funkcji do tej nazwy hosta, zazwyczaj przez pośrednika. Wydarzenia wysłane do tej domeny podczas tego okna nie zostały odebrane przez Mixpanel, a dane te nie mogą zostać przywrócone przez Mixpanel. * * Traffic sented to * * 'api.mixpanel.com' * *, * * 'api- js.mixpanel.com,' api- eu.mixpanel.com '* *, and * *' api- in.mixpanel.com '* * nie zostały naruszone. * * Usługa na tej nazwie hosta została nieumyślnie naruszona podczas usuwania infrastruktury końcowej "/ decide". Nazwy hostów były traktowane jako część punktu końcowego ze względu na nieprawidłowe zrozumienie zależności systemowych. Aby zapobiec tej klasie emisji, dodajemy monitorowanie ruchu dla nazw hostów "decyde.mixpanel.com" i "api- decide.mixpanel.com". Będziemy również wymagać potwierdzonego zerowego ruchu na poziomie hosta, zanim zostanie usunięta jakakolwiek nazwa hosta. * * Od tego czasu odrestaurowane usługi na * * 'decide.mixpanel.com'. - Co się stało? Starsze Mixpanel SDK nazwane punktem końcowym '/ decide', aby pobrać konfigurację dla [* * * Legacy Automatycznie śledzone zdarzenia mobilne * *] (https: / / docs.mixpanel.com / docs / tracking- methods / sdks / ios # legacy-automatically-tracked- events). [ogłosiliśmy przejście na emeryturę] (https: / / docs.mixpanel.com / changelogs # 2026- 01- 26), a przez pewien czas "/ decide" zwrócił odpowiedź "410". Oddzielnie, 'decide.mixpanel.com' i 'api- decide.mixpanel.com' działały jako aliasy dla naszych standardowych nazw hostów API. Na przykład, 'decide.mixpanel.com / track' połknął zdarzenia w ten sam sposób 'api- js.mixpanel.com / track' robi. Niektórzy klienci założyli konfiguracje proxy lub SDK, aby wysłać swój ruch do tych nazw hostów. W dniu 15 października o godzinie 7: 40 PM CDT, podczas końcowego czyszczenia punktu końcowego "/ decide", usunęliśmy rekordy DNS dla 'decide.mixpanel.com' i 'api- decide.mixpanel.com' i usunęliśmy obydwie nazwy hostów z naszego balancera obciążenia. Przed dokonaniem zmiany potwierdziliśmy, że ruch do punktu końcowego "/ zdecydować" spadł do zera. Jednak nasz monitoring mierzył ruch na podstawie punktu końcowego, a nie nazwy hosta. W związku z tym nie wykazano, aby inne wnioski, takie jak "/ track" i "/ flagi", nadal docierały do Mixpanel poprzez te nazwy. Od tego czasu wszystkie żądania do tej nazwy hosta nie powiodły się, w tym punkty końcowe takie jak "/ track", "/ engage", "/ groups" i "/ flags". * * * Wydarzenia i profile: * * Wydarzenia, profile i wszelkie dane przeznaczone dla [Punkty końcowe API Ingestion] (https: / / docs.mixpanel.com / reference / ingestion- api) dla tych nazw hostów podczas tego okna nigdy nie dotarły do Mixpanel, więc nie mamy kopii do przywrócenia. Jeżeli zachowałeś te dane gdzie indziej, np. w dziennikach proxy lub w magazynie danych, możesz je ponownie wysłać do Ingestion API [/ import] (https: / / docs.mixpanel.com / reference / import- events), [/ enterprise,] (https: / / docs.mixpanel.com / reference / profile- set) i [/ groups.mixpanel.com / reference / group- set- property). * * * Flagi: * * Prośby o flagę nie powiodły się. SDK obsługiwały ostatni zapisany wariant, jeśli taki istnieje, lub w inny sposób wartość rezerwową skonfigurowaną w Twoim kodzie. Czas środkowy, październik 2026 * * * 15 października, 7: 40 PM CDT: * * Zastosowanie ma usunięcie nazwy hosta. Wnioski do 'decide.mixpanel.com' i 'api- decide.mixpanel.com' zaczynają zawodzić. * * * 16 października 5: 22 AM CDT: * * Otrzymujemy pierwszy raport klienta. Początkowo uznaje się, że jest ona związana z planowaną emeryturą. * * * 21 października, 11: 42 AM CDT: * * Po zwiększeniu liczby raportów klientów o niepowodzeniu śledzenia proxy, identyfikujemy usunięcie nazwy hosta jako przyczynę. * * * 21 października, 12: 26 PM CDT: * * Przywrócimy nazwy gości. Decyzja pozostaje na emeryturze. * * * 21 października, 13: 51 PM CDT: * * Potwierdzamy ruch do przywróconych nazwisk. * * * 21 października, 8: 34 PM CDT: * * Incydent został rozwiązany. * * * * Root cause * * 1. Podczas "/ decide" przejścia na emeryturę, "decide.mixpanel.com" i "api- decide.mixpanel.com" zostały nieumyślnie usunięte. 2. Te nazwy hostów zostały skonfigurowane, aby akceptować wszystkie ruchy API, nie tylko żądania '/ decide', a zachowanie to było nieudokumentowane. 3. Nasze monitorowanie śledziło ruch do punktu końcowego "/ decide", ale nie do tych nazw hostów, więc kontrole przed zmianą nie wykazały, że inny ruch był nadal aktywny. 4. Ponieważ nazwy hostów i emerytowany punkt końcowy dzielą nazwę, wczesne raporty klientów zostały początkowo interpretowane jako oczekiwane skutki ogłoszonego "/ zdecydować" przejścia na emeryturę. Ta opóźniona eskalacja. * * * What we 're changing * * * * * Monitorowanie i ostrzeganie: * * Dodajemy monitorowanie ruchu i wskaźnika błędu i ostrzegamy o "decyde.mixpanel.com" i "api- decide.mixpanel.com", więc błędy są wykrywane automatycznie, a nie poprzez raporty klientów. * * * Audyt nazwy komputera: * * Kontrolujemy wszystkie publiczne nazwy hostów API i aliasy routingu dla podobnych nieudokumentowanych punktów wejścia, i będziemy przeglądać nowe nazwy hostów i aliasy, zanim przejdą na żywo. Śledzimy również ruch, który dociera na nieoczekiwaną nazwę hosta. * * * Bezpieczniejsze usuwanie: * * Przed jakąkolwiek przyszłą zmianą nazwy hosta publicznego, potwierdzimy zerowy ruch na poziomie nazwy hosta, i zidentyfikujemy i skontaktujemy się z wszelkimi projektami, które nadal go używają. * * * Komunikacja z klientem: * * Będziemy informować klientów z wyprzedzeniem o zmianach infrastruktury materialnej, które wpływają na nazwy gości publicznych, w tym publikowanie ich na osi czasu w naszym changelog. * * Już wdrożono: * * * Przywrócony 'decide.mixpanel.com' i 'api- decide.mixpanel.com.' * '/ decide' pozostaje na emeryturze * * * Common questions * * Czy moje dane były naruszone? Tylko w przypadku, gdy Twój SDK lub proxy wysłał żądania do 'decide.mixpanel.com' lub 'api- decide.mixpanel.com' między 15 października a 21 października. Dane przesłane w tym oknie nie zostały otrzymane i nie mogą zostać przywrócone przez Mixpanel. Jeśli zachowałeś kopię tych danych, możesz je ponownie wysłać do Mixpanel używając naszych punktów końcowych API Zażywienia, takich jak "/ import" dla wydarzeń. Czy muszę coś zmienić? Nie, domeny znowu działają. Zalecamy użycie 'api.mixpanel.com'\ (lub 'api- eu.mixpanel.com' / 'api- in.mixpanel.com' dla rezydencji danych w UE i Indiach\) jako domeny API. * * * Is * * 'decide' coming back? Nie. Pozostaje na emeryturze, jak ogłoszono, i jest oddzielony od 'decyde.mixpanel.com' hostname. Przepraszamy za zakłócenia. Jeśli masz pytania dotyczące projektu, skontaktuj się z zespołem konta lub obsługą Mixpanel.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 8 października 2026 16:32 UTCinvestigating

   Obecnie mamy do czynienia z opóźnieniami w zakresie naszego gazociągu przetwarzania danych, który wpływa na dane w czasie rzeczywistym dotyczące projektów włączonych do amerykańskich projektów, co powoduje opóźnienia dla podzbioru projektów. Podczas gdy brak jest danych, nasz zespół inżynieryjny aktywnie bada sprawę i pracuje nad jak najszybszym przywróceniem funkcjonalności w czasie rzeczywistym. Dziękujemy za cierpliwość. Jeśli masz jakieś pytania, skontaktuj się ze wsparciem.

2. 8 października 2026 17:32 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 8 października 2026 18:31 UTCidentified

   Zidentyfikowaliśmy przyczynę opóźnienia połknięcia jako problem na wcześniejszych etapach z naszym dostawcą pamięci masowej w chmurze Google Cloud, wpływając na podzbiór amerykańskich projektów. Google potwierdziło, że jest to kwestia o wysokim priorytecie, ale nie dostarczył jeszcze ETA. Zastosowaliśmy środki łagodzące, aby zapewnić płynny powrót do zdrowia po oczyszczeniu. Żadne wydarzenia nie są stracone. Jest to ściśle opóźnienie połknięcia, wszystkie dane, których to dotyczy, będą nadal przetwarzane po rozwiązaniu problemu.

4. 8 października 2026 19:30 UTCmonitoring

   Nasze pomiary pokazują, że spożycie zostało zatrzymane i nie ma już opóźnień. Google nie potwierdziło jeszcze rozwiązania podstawowego problemu wyższego szczebla na ich końcu, więc nadal uważnie monitorujemy w przypadku nawrotu.

5. 8 października 2026 21:30 UTCmonitoring

   Od ostatniej aktualizacji nic się nie zmieniło, nadal nie obserwujemy aktywnego opóźnienia spożycia, a wszystkie systemy pozostają zdrowe. Kontynuujemy obserwację.

6. 8 października 2026 22:30 UTCmonitoring

   Nadal monitorujemy wszelkie dalsze problemy.

7. 8 października 2026 23:30 UTCmonitoring

   Systemy pozostają stabilne bez ponownego wystąpienia opóźnienia spożycia. Obserwujemy sprawy, czekając na ostateczne potwierdzenie od naszego dostawcy.

8. 9 października 2026 00:22 UTCresolved

   Ten incydent został rozwiązany. Zagadnienie z naszym dostawcą pamięci masowej w chmurze zostało ustalone, a nasz rurociąg spożywczy działa normalnie bez żadnych opóźnień. W czasie tego incydentu nie doszło do utraty żadnych zdarzeń, wszystkie dane, których dotyczyło, zostały w pełni przetworzone. Dziękuję za cierpliwość podczas tego incydentu.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 26 sierpnia 2026 21:39 UTCinvestigating

   Mixpanel doświadcza zdegradowanych wyników Query API, co prowadzi do odpowiedzi HTTP 500 podczas wyszukiwania raportów dla projektów z US Data Residency. Projekty z UE i IN Residency pozostają nienaruszone. Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad przywróceniem normalnej funkcjonalności. Umieścimy aktualizacje postępu na naszej stronie statusu. Jeśli masz jakieś pytania, skontaktuj się ze wsparciem.

2. 26 sierpnia 2026 22:11 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 26 sierpnia 2026 22:28 UTCmonitoring

   Zaimplementowano rozwiązanie i widzimy lepsze wskaźniki sukcesu dla Query API. Będziemy nadal monitorować, aby zapewnić stabilność.

4. 26 sierpnia 2026 22:45 UTCresolved

   Ten incydent został rozwiązany.

5. 8 września 2026 18:25 UTCpostmortem

   # Mixpanel RCA: Tymczasowe zakłócenie serwisu zapytań dla projektów USA 26 sierpnia 2026 # Streszczenie W dniach od 26 sierpnia 2026 roku do 15: 19 PT, w regionie USA odnotowano niepowodzenia w ładowaniu raportów i prowadzeniu zapytań przez Mixpanel UI i Query API. Podczas tego okna niektóre pytania w regionie nie powiodły się lub zwróciły błędy. * * Nie utracono danych klientów, a spożycie danych nie miało wpływu. * * Wszystkie zdarzenia nadal były gromadzone i przechowywane normalnie przez cały incydent; po przywróceniu usługi zapytania, wszystkie raporty odzwierciedlały kompletne, dokładne dane bez potrzeby działania klienta. Przyczyna została zidentyfikowana jako niedawno wdrożone wewnętrzne narzędzie do powtórnego rozpoznawania zapytania, zdolność naszych inżynierów do ponownego uruchomienia kopii poprzednich zapytań do debugowania wydajności, który niespodziewanie napisał duże ilości danych na dyskach naszych serwerów zapytania, zużywając pojemność pamięci masowej serwery muszą działać. Kiedy te dyski się wypełniły, zainfekowane serwery wycofały się z eksploatacji. Usługa została przywrócona, uszkodzone serwery zostały przywrócone do sieci, a wewnętrzne oprzyrządowanie zostało wyłączone. Poniższe środki zaradcze dodają zabezpieczenia pamięci masowej w celu usunięcia zdolności wewnętrznych narzędzi do zużycia zasobów na serwerach zapytań i są zaprojektowane, aby zapobiec tej klasie awarii ponownie w przyszłości. Co się stało Silnik zapytania Mixpanel działa na flotę serwerów, które używają zestawu lokalnych woluminów pamięci masowej do buforowania danych potrzebnych do szybkiej odpowiedzi na zapytania. Oddzielnie nasi inżynierowie używają narzędzi do powtarzania zapytania diagnostycznego, co umożliwia naszym inżynierom odtwarzanie i debugowanie wyników zapytania. Podczas stosowania diagnostycznego przywracania zapytania do dużego, skomplikowanego zapytania, błąd oprogramowania spowodował, że powtórka zapytania przechwytuje się w całej flocie zamiast pozostawać ograniczonym do jednego serwera. Ponadto spowodowało to znacznie więcej danych niż zamierzano zapisać bez terminowej eksmisji na jednym serwerze. Następnie dwa czynniki zwiększyły wpływ tej kwestii: * Jeden pełny wolumin pamięci masowej wziął serwer całkowicie z usługi. Każdy serwer traktuje swoją pamięć podręczną jako niezdrową, jeżeli którykolwiek z jego woluminów pamięci masowej przekracza próg użytkowania, nawet jeśli wszystkie inne woluminy są zdrowe. Dane z powtórki zostały zapisane do jednego konkretnego wolumenu na każdym serwerze, więc serwery w całym regionie nie sprawdziły się prawie jednocześnie. * Limity czyszczenia nie uwzględniały wielkości danych. Zabezpieczenie ograniczające dane dotyczące odtwarzania na dysku liczyły pozycje na poziomie aplikacji, a nie bajty na poziomie systemu plików, więc niewielka liczba niespodziewanie dużych przechwytywaczy przeszła kontrolę przy zużyciu większości pojemności. Umożliwiły one łącznie jeden strumień pracy debugowania, który zwykle ma nieistotny ślad, aby przerwać zapytanie o produkcję w całym regionie USA. # Timeline\ (Pacific Time, August 26, 2026\) * * * 2: 00 PM * * - Napisana została pierwsza nadmiarowa powtórka diagnostyczna; wolumeny przechowywania zaczęły osiągać swoją pojemność, a wkrótce po tym liczba zapytań zaczęła spadać. * * * 2: 17 PM * * - Automatyczne alarmowanie wzywał oncall inżynier; śledztwo rozpoczęło się natychmiast i dodatkowych inżynierów zostały zaangażowane. * * * 2: 39 PM * * - Zgłoszony incydent na stronie statusu; baner in- app wyświetlany o 14: 40 PM. * * * 2: 53 PM * * - Zidentyfikowana przyczyna korzenna; wysiłki w zakresie odzyskiwania rozpoczęły się w pierwszej dotkniętej grupie serwerów. * * * 3: 19 PM * * - Usługa zapytań przywrócona dla przeważającej większości ruchu; ostatnia grupa serwerów w pełni odzyskała o 3: 27 PM. * * * 3: 45 PM * * - Incydent rozwiązany po stabilnym okresie obserwacji. Rękopis diagnostyczny, który wywołał ten problem, został w pełni wyłączony tego samego wieczoru. # Root cause 1. * * Błąd oprogramowania w naszej repliki zapytania tooling spowodowane unlimited pisze do przechowywania produkcji. * * Niedawno zastosowana zdolność do odtwarzania zapytań źle zaszła, co spowodowało rozprzestrzenienie się przechwytywania na każdy serwer w regionie i zapisanie o wiele większej ilości danych do woluminów, niż zakładano. 2. * * Replay files consumed disk capacity that query serving depended on. * * Tooling replay napisał swoje pliki na lokalnych dyskach serwerów query, tak uciekające dane replay wyczerpane pojemności pamięci, które serwery muszą odpowiedzieć na zapytania. 3. * * Zabezpieczenia tylko częściowo uwzględniały zachowanie. * * Polityka czyszczenia danych dotyczących powtórnej diagnostyki ograniczyła liczbę pozycji na dysku, ale nie ich całkowitą wielkość, więc nie angażuje. Alertowanie na wolumenach pamięci masowej oznaczało wzrost, ale nie było eskalowane jako krytyczne w oparciu o perserwer, co opóźniło wykrycie aż do niepowodzenia zapytania. # What we 're change Stan końcowy, który budujemy w kierunku: danych z wewnętrznej diagnostyki odtworzenia zapytania przechowywanych w dedykowanym magazynie obiektów, nie umieszczając obciążenia na serwerach zapytania produkcji. Już wdrożono: * * * Wyłączył wewnętrzne oprzyrządowanie * *, które spowodowało incydent, i naprawił problem, więc przechwytywania diagnostyczne są ograniczone do jednego serwera i określona klasa zapytań jest obsługiwana poprawnie. * * * Dokumentował ukierunkowaną procedurę odzyskiwania * * zastosowaną w czasie incydentu, tj., oczyszczenie tylko dotkniętego wolumenu pamięci zamiast ponownego uruchomienia pełnych grup serwerów, w naszych operacyjnych runbookach, skracając czas odzyskiwania, jeśli jakikolwiek wolumen przepustowości kończy się w przyszłości. W toku: * * * Poziom filesystem-, znaczne ograniczenia dotyczące danych diagnostycznych * *, ograniczenie całkowitej liczby bajtów na dysku zamiast liczby elementów, więc przerośnięte przechwytywania są odrzucane lub eksmitowane, zanim będą mogły wpłynąć na pojemność wolumenu. * * * Stricter ostrzeganie pamięci masowej * *, eskalowanie nasycenia wolumenu serwera jako krytycznego, zanim może wpłynąć na kontrolę zdrowia. * * * Przenoszenie danych z query do dedykowanego obiektu pamięci masowej, * * więc nie zużywa zasobów na serwerach zapytania produkcji. # Wspólne pytania Czy jakieś dane zaginęły? Nie. Zażywanie danych nie uległo zmianie podczas całego incydentu: zdarzenia były nadal zbierane, w kolejce i przechowywane normalnie. Tylko zdolność do zapytania została przerwana. Po przywróceniu usługi wszystkie raporty odzwierciedlały kompletne dane. * * * Czy zostały zapisane raporty, deski rozdzielcze lub ustawienia projektu dotknięte? * * Nie. Incydent dotyczył tylko wykonania zapytania. Nic nie zmieniło się w twoim projekcie. * * * Dlaczego miało to wpływ na wiele amerykańskich projektów jednocześnie? * * Przerośnięte dane diagnostyczne zapisane na dyskach każdego serwera zapytań w prawie tym samym czasie, a każdy serwer usuwa się z usługi, gdy jeden wolumin wypełnia. Zapobieganie wewnętrznemu oprzyrządowaniu przed spożywaniem pamięci masowej serwera query- jest główną częścią naszych prac naprawczych. * * * How is this prevent going forward? * * Kwestia oprzyrządowania została rozwiązana, a oprzyrządowanie pozostaje wyłączone do czasu wprowadzenia znacznych limitów. Ostrzeżenie o przechowywaniu jest zaostrzane, więc nasycenie jest wyłapywane zanim wpływa na obsługę zapytania. Strukturalnie, przenosimy dane diagnostyczne z serwerów zapytania produkcji całkowicie, więc wewnętrzne dane debugowania nie zużywają przechowywania na serwerach odpowiedzialnych za przetwarzanie zapytań. Przepraszamy za zakłócenia, a raporty czasowe były niedostępne. Prosimy o kontakt z zespołem konta lub wsparcie w razie jakichkolwiek pytań.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 19 sierpnia 2026 23:20 UTCidentified

   Obecnie doświadczamy problemów z popularyzacją właściwości zdarzeń w menu rozwijanym. Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad przywróceniem funkcjonalności. Jeśli masz jakieś pytania, skontaktuj się ze wsparciem @ mixpanel.com

2. 20 sierpnia 2026 01:04 UTCidentified

   Kontynuujemy prace nad rozwiązaniem tego problemu.

3. 20 sierpnia 2026 02:52 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 20 sierpnia 2026 03:05 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 sierpnia 2026 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 sierpnia 2026 08:39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 6 sierpnia 2026 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 sierpnia 2026 13:32 UTCresolved

   This incident has been resolved.

1. 22 lipca 2026 08:03 UTCinvestigating

   Obecnie doświadczamy problemów z agentem Mixpanel w ramach webapp. Nasz zespół inżynieryjny został powiadomiony i bada problem i pracuje nad przywróceniem jego funkcjonalności. Doceniamy waszą cierpliwość, pracując nad rozwiązaniem tej sprawy. Jeśli masz jakieś pytania, skontaktuj się ze wsparciem.

2. 22 lipca 2026 09:52 UTCinvestigating

   zespół kontynuuje badanie problemu i kolejnych kroków. Dzięki za cierpliwość.

3. 22 lipca 2026 10:55 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

4. 22 lipca 2026 14:47 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 11 lipca 2026 07:53 UTCinvestigating

   Obecnie mamy do czynienia z opóźnieniami w zakresie naszego gazociągu przetwarzania danych, który wpływa na dane w czasie rzeczywistym dotyczące projektów włączonych do amerykańskich projektów, co powoduje opóźnienia dla podzbioru projektów. Podczas gdy brak jest danych, nasz zespół inżynieryjny aktywnie bada sprawę i pracuje nad jak najszybszym przywróceniem funkcjonalności w czasie rzeczywistym. Dziękujemy za cierpliwość. Jeśli masz jakieś pytania, skontaktuj się ze wsparciem.

2. 11 lipca 2026 09:17 UTCinvestigating

   Nadal badamy tę kwestię.

3. 11 lipca 2026 10:15 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

4. 11 lipca 2026 12:54 UTCidentified

   Kontynuujemy prace nad rozwiązaniem tego problemu.

5. 11 lipca 2026 14:25 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

6. 11 lipca 2026 15:54 UTCresolved

   Ten incydent został rozwiązany.

7. 16 lipca 2026 23:47 UTCpostmortem

   # Streszczenie Pomiędzy 11: 35 PM PT w dniu 10 lipca a 7: 19 AM PT w dniu 11 lipca 2026 * *, spożycie danych dla projektów Mixpanel w regionie USA przebiegał w tyle do ~ 2 godzin. W tym oknie raporty i tablice rozdzielcze tymczasowo wykazały niekompletne dane - niedawne przedziały czasowe mogą wydawać się ostrymi, sztucznymi spadkami wskaźników, takimi jak aktywni użytkownicy czy przychody. * * No data was lost. * * Wszystkie zdarzenia były ustawiane w kolejce w sposób trwały i przetwarzane w całości po oczyszczeniu zaległości; metryka powróciła do dokładnych wartości samodzielnie, bez konieczności działania klienta. Przyczyna powstała w naszych kontrolach spożycia: w przypadku niewielkiej liczby bardzo dużych projektów, wskaźniki spożycia, na które pozwoliliśmy, wyszły z równowagi z możliwościami zapewnianymi dla tych projektów. Duży historyczny import - w pełni zgodne z prawem wykorzystanie platformy - został zatem przyjęty szybciej niż ich infrastruktura może wchłonąć, a dwie właściwości naszego rurociągu zamieniły to zlokalizowane przeciążenie w regionalne opóźnienie. Poniższe poprawki regulują te kontrole tak, że każdy import, dowolnej wielkości, jest automatycznie utrzymywany w granicach bezpieczeństwa. Co się stało Gazociąg mieszankowy Mixpanel jest ostrzejszy i wielolokatorski: dane każdego projektu są rozprowadzane w zestawie partycji wielkości dla jego oczekiwanej wielkości, a dla przepustowości, wydarzenia wielu klientów są przetwarzane razem w partiach. Projekt ten zapewnia wysoką wydajność, ale zależy od jednego niezmiennego: tempo, w jakim przyznajemy, że ruch projektu musi odpowiadać przepustowości zapewnionej dla projektu. Kiedy ten niezmienny utrzymuje, nawet bardzo duży import jest wchłaniany płynnie. Tutaj nie wytrzymało. Niewielka liczba bardzo dużych danych historycznych, które importowano, opierała się na projektach, których dozwolony poziom spożycia wzrósł z czasem znacznie powyżej ich dostępnej zdolności podziału. Nadmiar objętości skoncentrowany na określonych partycjach jako * * hot spoty * *, nasycając część floty strumieniowej obsługującej je. Następnie dwa czynniki zwiększyły wpływ: * * * Związane, wielolokatorskie przetwarzanie wzmocniło gorące punkty. * * Ponieważ wydarzenia wielu klientów podróżują razem w partiach, powolność i niepowodzenia na przeładowanych partycjach opóźniło niepowiązane wydarzenia klientów dzielących te partie. Automatyczne skalowanie było nieskuteczne. Dodanie przepustowości nie może rozwiązać tego rodzaju gorącego punktu, ponieważ przeciążone przegrody pozostają przymocowane do tej samej infrastruktury, a ograniczenie przepustowości w części naszej infrastruktury strumieniowej uniemożliwiło wejście w życie dodatkowej przepustowości. Razem zamienili to, co powinno być krótkim, samouzdrawiającym spowolnieniem w wielogodzinne opóźnienie wymagające ręcznej interwencji. # Timeline\ (Pacific Time, July 10- 11\) * * * 11: 35 PM * * - Automatyczne alarmowanie wykryło zaległości w spożyciu; inżynier on-call uruchomiony natychmiast. * * * 12: 49 AM * * - Zgłoszony incydent na stronie statusu; wpływ został przebadany tylko w regionie USA. * * * 1: 23 AM * * - Największy udział przywozu został wstrzymany. * * * 1: 55- 6: 48 AM * * - Progresywne ograniczenia: dodatkowe źródła ruchu zatłoczone, pewne dane zaległe odroczone wraz z umową właściciela klienta, izolacja awarii włączone w rurociągu, a dotknięte węzły infrastruktury zastąpione. * * * 7: 19 AM * * - Backlog w pełni przetworzony; wszystkie projekty aktualne. Strona statusu przeniesiona do monitorowania, a następnie rozwiązana po stabilnym okresie obserwacji. # Root cause 1. * * Limity wskaźnika spożycia niezgodne z rezerwą mocy. * * W przypadku projektów związanych z prowadzeniem pojazdów, stawki, do których przyzna się nasza platforma, rosły w stopniu sprzecznym z zapewnioną im infrastrukturą, tak więc legalny import o dużej wielkości został wprowadzony szybciej niż ich partycje mogły wchłonąć. To jest ogólnoustrojowa przyczyna. Sam przywóz był legalnym wykorzystaniem platformy. 2. * * Związane, wielolokatorskie przetwarzanie wzmocniło przeciążenie. * * Usterki na przeładowanych partycjach opóźniły wydarzenia niepowiązanych klientów dzielących te same partie przetwarzania, rozprzestrzeniając problem zlokalizowany na całej platformie. 3. * * Ruch do przeładowanych partycji nie mógł być redystrybuowany. * * Przypisanie części do serwera w warstwie strumieniowej nie było świadome obciążenia, więc gorące punkty pozostawały przypięte do tych samych serwerów, niezależnie od wielkości floty - całkowita pojemność była wystarczająca, ale nie można było tego znieść. Ograniczenie skalowania w komponencie naszej infrastruktury strumieniowej dodatkowo to zwiększyło, zapobiegając zwiększaniu wydajności, co opóźniło diagnozę aż inżynierowie interweniowali ręcznie. # What we 're change Stan końcowy, który budujemy w kierunku: * * limitów połknięcia każdego projektu automatycznie dopasowuje się do jego mocy, tak, że import o dowolnej wielkości, w tym pełne historyczne backfishes i syncs magazynów danych, może działać bez wcześniejszej koordynacji, a wielkość jednego projektu nie może wpływać na świeżość danych innego. * *. Już wdrożony - ulepszenie naszego sposobu przyjmowania: * * * Ulepszona obsługa Hot- spot. * * Rozkład ruchu w warstwie strumieniowej jest teraz obciążony, rozprzestrzenianie skoncentrowanego obciążenia bardziej równomiernie w całej flocie, a poszczególne elementy problemowe są teraz ponownie próbowane oddzielnie zamiast trzymać resztę ich partii - redukując, choć nie eliminując, wpływ miejscowego przeciążenia może mieć na niezwiązany ruch. * * * Przestawiono obciążenie pracą o najwyższym wolumenie na odpowiednią infrastrukturę o priorytecie ryzyka. Już wdrożono - zmieniamy sposób obsługi usługi transmisji strumieniowej trzeciej partii: * * * Audyt i ponowne dostosowanie profilu wydajności floty * * tak poszczególne serwery mają znacznie więcej miejsca na skoncentrowany ładunek, i pracował z dostawcą, aby rozwiązać ograniczenie skalowania napotkane podczas incydentu. W toku: * * * Poziom wiedzy o możliwości ograniczający * * - likwidacja luk między indywidualnie przyznanymi limitami stawek projektów a rzeczywistymi możliwościami projektu, rozszerzając stawkę ograniczającą się do dróg spożycia, które wcześniej jej nie posiadały, i łącząc wszelkie przyszłe zwiększenie limitu do zwiększenia zdolności produkcyjnych, które ma na celu zapobieżenie powtarzaniu się tej klasy pomyłek. * * * Generowane monitorowanie głośności i ostrzeganie * * tak, aby nieprawidłowa konfiguracja przepustowości została wykryta i poprawiona, zanim może wpłynąć na każdego klienta. * Ocena silniejsza izolacja obciążenia pracą / zaległości odzyskiwania priorytetyzacja dla trasy transportu luzem / backfill, więc historyczne importu mają ograniczony wpływ na ruch na żywo # Wspólne pytania Czy jakieś dane zaginęły? Nie. Wydarzenia były ustawiane w kolejce przez cały incydent i były w pełni przetwarzane po oczyszczeniu zaległości. Wszelkie krople metryczne widoczne podczas okna były artefakt wyświetlania opóźnienia i samokorekcji. * * * Czy muszę koordynować duży import lub backfills z Mixpanel? * * Nie. Naszym celem jest, aby platforma zachować każdy import w bezpiecznych cenach automatycznie, tak, że backfishes i syncs magazynowych może działać bez planowania lub powiadomienia. Nadal przeprowadzamy kontrole zdolności, które to zapewniają. W międzyczasie, jeśli planujesz niezwykle duży import lub backfill, zalecamy koordynację z zespołem konta, abyśmy mogli potwierdzić pojemność z góry. * * * How is this prevent going forward? * * Rozwiązanie systemowe polega na zaostrzaniu luk między indywidualnie przyznanymi limitami stawek dla projektów a rzeczywistą przepustowością każdego projektu, a także na poszerzaniu stawki ograniczającej się do dróg spożycia, które wcześniej jej brakowało - w ten sposób przeciążenie tego rodzaju zostaje zatrzymane przy przyjęciu. Ponadto, ograniczenie skalowania, które przedłużyło ten incydent, jest ustalone, rurociąg teraz ponownie poszczególne elementy problemowe oddzielnie tak lokalizowane przeciążenie ma znacznie mniejszy wpływ na niezwiązanych ruchu, a ruch masowy jest dalej izolowany od ruchu na żywo. * * * Czy poszczególne projekty mogą być traktowane priorytetowo podczas odzyskiwania? * * Zdolność ta nie istniała podczas incydentu - wszystkie projekty odzyskane w tym samym tempie. Oceniamy mechanizmy ustalania priorytetów w zakresie odzyskiwania zaległości w ramach naszych dalszych działań. Przepraszamy za zakłócenie i za obawy, które spowodowały tymczasowo upośledzone wskaźniki. Prosimy o kontakt z zespołem konta lub wsparcie w razie jakichkolwiek pytań.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 29 czerwca 2026 19:47 UTCinvestigating

   Mixpanel doświadcza zdegradowanej wydajności z naszym Query API, w tym zwiększonej latencji. Możesz zobaczyć powolne wczytywanie raportów lub błędów zapytania. Dziękujemy za cierpliwość, podczas gdy nasi inżynierowie pracują nad przywróceniem normalnej funkcjonalności. Umieścimy aktualizacje postępu na naszej stronie statusu. Jeśli masz jakieś pytania, skontaktuj się ze wsparciem.

2. 29 czerwca 2026 21:04 UTCidentified

   Problem został zidentyfikowany i jest w trakcie wdrażania.

3. 29 czerwca 2026 22:42 UTCidentified

   Ustabilizowaliśmy opóźnienie, ale nasz zespół nadal bada przyczynę degradacji. Będziemy nadal publikować aktualizacje w miarę postępu śledztwa. Dziękuję za cierpliwość.

4. 30 czerwca 2026 02:15 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

5. 30 czerwca 2026 03:30 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 3 czerwca 2026 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 czerwca 2026 20:17 UTCidentified

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

3. 3 czerwca 2026 21:27 UTCresolved

   This incident has been resolved.

1. 2 czerwca 2026 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 czerwca 2026 12:31 UTCidentified

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

3. 2 czerwca 2026 14:31 UTCmonitoring

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

4. 2 czerwca 2026 16:53 UTCresolved

   This incident has been resolved.

1. 1 czerwca 2026 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 czerwca 2026 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 czerwca 2026 15:29 UTCidentified

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

4. 1 czerwca 2026 16:38 UTCmonitoring

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

5. 1 czerwca 2026 19:42 UTCresolved

   This incident has been resolved.

1. 19 maja 2026 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 maja 2026 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 maja 2026 20:23 UTCmonitoring

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

4. 19 maja 2026 21:18 UTCresolved

   This incident has been resolved.

1. 14 maja 2026 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 maja 2026 23:48 UTCidentified

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

3. 15 maja 2026 10:19 UTCidentified

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

4. 15 maja 2026 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 maja 2026 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 maja 2026 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 maja 2026 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 maja 2026 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 maja 2026 21:23 UTCidentified

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

10. 15 maja 2026 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 maja 2026 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 maja 2026 01:52 UTCmonitoring

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

13. 16 maja 2026 02:50 UTCresolved

    This incident has been resolved.

14. 21 maja 2026 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 maja 2026 16:34 UTCidentified

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

2. 13 maja 2026 21:40 UTCidentified

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

3. 14 maja 2026 13:35 UTCresolved

   This incident has been resolved.

1. 12 maja 2026 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 maja 2026 17:46 UTCidentified

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

3. 12 maja 2026 20:24 UTCmonitoring

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

4. 12 maja 2026 21:44 UTCresolved

   This incident has been resolved.

1. 6 maja 2026 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 maja 2026 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 maja 2026 20:04 UTCresolved

   This incident has been resolved.

1. 9 kwietnia 2026 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 kwietnia 2026 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 kwietnia 2026 21:44 UTCresolved

   This incident has been resolved.

1. 16 marca 2026 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 marca 2026 19:29 UTCmonitoring

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

3. 16 marca 2026 21:47 UTCresolved

   This incident has been resolved.

1. 2 marca 2026 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 marca 2026 21:09 UTCidentified

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

3. 2 marca 2026 21:09 UTCmonitoring

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

4. 2 marca 2026 21:53 UTCresolved

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