Historia awarii Mixpanel

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.

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.

1. 2 marca 2026 19:48 UTCinvestigating

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

2. 2 marca 2026 19:49 UTCidentified

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

3. 2 marca 2026 19:50 UTCmonitoring

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

4. 2 marca 2026 20:08 UTCmonitoring

   We have partially mitigated the issue and are continuing to monitor for any further impact. We are also actively working to address the root cause.

5. 3 marca 2026 01:43 UTCresolved

   This incident has been resolved.

1. 2 marca 2026 18:41 UTCinvestigating

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

2. 2 marca 2026 18:44 UTCidentified

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

3. 2 marca 2026 18:45 UTCmonitoring

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

4. 2 marca 2026 18:53 UTCresolved

   This incident is resolved.

1. 30 stycznia 2026 18:39 UTCinvestigating

   We are currently experiencing delays with Cohort Syncs to external destinations, including custom webhooks and engagement platforms. Our team is investigating the issue and actively working on a resolution. We sincerely apologize for the inconvenience and thank you for your kind understanding. If you have any questions, please contact support

2. 30 stycznia 2026 20:05 UTCmonitoring

   A fix has been implemented, and we are monitoring the results. Recurring cohort syncs should resume on the next scheduled run with no additional action required.

3. 30 stycznia 2026 22:14 UTCmonitoring

   We are continuing to monitor for further issues. We have identified that a subset of Cohort Syncs are still experiencing delays and are working to resolve these remaining cases.

4. 31 stycznia 2026 01:48 UTCmonitoring

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

5. 31 stycznia 2026 02:41 UTCresolved

   This incident has been resolved.