Mixpanel driftsforstyrrelser

1. 21. oktober 2026 kl. 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 kl. 20.15 UTCresolved

   This incident has been resolved.

1. 21. oktober 2026 kl. 22.28 UTCmonitoring

   Vi har modtaget rapporter om, at anmodninger om decide.mixpanel.com er mislykket. Enhver trafik sendt gennem decide.mixpanel.com kan blive påvirket, herunder feature flag og begivenhed sporing. For at genoprette tjenesten nu, punkt anmodninger til api.mixpanel.com (US), api- eu.mixpanel.com (EU), eller api- in.mixpanel.com (IN), afhængigt af dit projekt er Data Residency. Vi har fundet en afbødning og overvåger resultaterne. Vi ser trafikken genoprettet. Vi vil sende statusopdateringer på vores statusside. Hvis du har spørgsmål, bedes du kontakte support.

2. 22. oktober 2026 kl. 01.34 UTCresolved

   Denne hændelse er blevet løst.

3. 24. oktober 2026 kl. 01.58 UTCpostmortem

   # * * Mixpanel RCA: Anmodninger til * * [* * decide.mixpanel.com * *] (http: / / decide.mixpanel.com) * * Mislykkedes, 15. oktober - 21, 2026 * * # # # * * Oversigt * * Fra 15. okt 2026 til 21. okt 2026 mislykkedes anmodninger sendt til 'decide.mixpanel.com' og 'api- decide.mixpanel.com'. Dette påvirkede kunder, der sendte event tracking, profilopdateringer, eller feature flag anmodninger til dette værtsnavn, normalt gennem en proxy. Begivenheder sendt til dette domæne i dette vindue blev ikke modtaget af Mixpanel, og disse data kan ikke gendannes af Mixpanel. * * Trafik sendt til * * 'api.mixpanel.com' *, * * 'api- js.mixpanel.com', 'api- eu.mixpanel.com' *, og * * 'api- in.mixpanel.com' * * blev ikke påvirket. * * Tjenesten på dette værtsnavn blev utilsigtet påvirket, mens vi fjernede '/ beslutte' endpoint infrastruktur. Værtnavne blev behandlet som en del af endepunktet på grund af en forkert forståelse af systemafhængigheder. For at forhindre denne klasse af spørgsmål, vi tilføjer trafik overvågning for "decide.mixpanel.com" og "api- decide.mixpanel.com" værtsnavne. Vi vil også kræve bekræftet nul trafik på værtsnavn niveau, før nogen værtsnavn er fjernet. * * Vi har siden genoprettet tjenesten på * * 'decide.mixpanel.com'. Hvad skete der? Old Mixpanel SDKs kaldte '/ beslutte' endpoint for at hente konfiguration til [* * Legacy automatisk Tracked Mobile Events * *] (https: / / docs.mixpanel.com / docs / tracking- methods / sdks / ios # legacy- automatically- tracked- events). Vi [annoncerede endpoint 's pensionering] (https: / / docs.mixpanel.com / changelogs # 2026- 01- 26), og i nogen tid' / beslutte 'er returneret et' 410 'svar. Separately, 'decide.mixpanel.com' og 'api- decide.mixpanel.com' fungerede som aliaser for vores standard API værtsnavne. For eksempel, 'decide.mixpanel.com / track' indtaget begivenheder på samme måde 'api- js.mixpanel.com / track' gør. Nogle kunder havde oprettet proxyer eller SDK konfigurationer til at sende deres trafik til disse værtsnavne. Den 15. oktober kl. 7: 40 CDT, under den endelige oprydning af '/ Beslut' endepunktet, fjernede vi DNS optegnelser for 'decide.mixpanel.com' og 'api- decide.mixpanel.com' og fjernede begge værtsnavne fra vores load balancer. Før ændringen bekræftede vi, at trafikken til '/ Beslut' -endepunktet var faldet til nul. Men vores overvågning målt trafik ved endepunkt snarere end ved værtsnavn. Den viste derfor ikke, at andre anmodninger, såsom "/ track" og "/ flag", stadig nåede Mixpanel gennem disse værtsnavne. Fra da af mislykkedes alle anmodninger til dette værtsnavn, herunder endepunkter som "/ track", "/ act", "/ groups" og "/ flag". * * * Begivenheder og profiler: * * Begivenheder, Profiler, og alle data beregnet til [Ingestion API endepunkter] (https: / / docs.mixpanel.com / reference / ingestion- api) til disse værtsnavne under dette vindue aldrig nået Mixpanel, så vi har ikke en kopi til at genoprette. Hvis du har gemt disse data andre steder, såsom i proxylogs eller i dit datalager, kan du sende dem tilbage til Ingestion API 's [/ import] (https: / / docs.mixpanel.com / reference / import- events), [/ act,] (https: / / docs.mixpanel.com / reference / profile- set) og [/ groups] (https: / docs.mixpanel.com / reference / group- set- egenskab). * * * Feature flag: * * Feature flag anmodninger sendt til disse værtsnavne mislykkedes. SDK tjente den sidste gemte variant, hvis man eksisterede, eller ellers fallback værdi konfigureret i din kode. # # # Timeline\ (Central Time, oktober 2026\) * * * 15 oktober, 7: 40 PM CDT: * * Værtsnavnet fjernes. Anmodninger om 'decide.mixpanel.com' og 'api- decide.mixpanel.com' begynder at svigte. * * * Oktober 16, 5: 22 AM CDT: * * Vi modtager den første kunderapport. Den anses i første omgang for at være relateret til den planlagte pensionering. * * * 21. oktober, 11: 42. Efter en stigning i kunderapporter om sporing mislykkes for proxyer, vi identificere værtsnavnet fjernelse som årsagen. * * * 21 oktober, 12: 26 PM CDT: * * Vi genskaber værtsnavnene. '/ beslutte' forbliver pensioneret. * * * 21 oktober, 1: 51 PM CDT: * * Vi bekræfter, at trafikken til de restaurerede værtsnavne er kommet sig. * * * 21 oktober, 8: 34 PM CDT: * * Hændelsen er løst. # # # * * Rodårsag * * 1. Under '/ beslutte' pensionering, 'decid.mixpanel.com' og 'api- decid.mixpanel.com' blev utilsigtet fjernet. 2. Disse værtsnavne var blevet konfigureret til at acceptere al API trafik, ikke kun '/ beslutte' anmodninger, og denne adfærd var udokumenteret. 3. Vores overvågning sporet trafik til '/ beslutte' endpoint, men ikke til disse værtsnavne, så pre- change kontrol viste ikke, at anden trafik var stadig aktiv. 4. Da værtsnavnene og det pensionerede endepunkt deler et navn, blev tidlige kunderapporter oprindeligt tolket som forventede virkninger af den annoncerede '/ beslutte' pensionering. Denne forsinkede eskalering. Hvad vi ændrer * * * Overvågning og varsling: * * Vi tilføjer trafik og overvågning af fejlhastigheder og alarmering for 'decide.mixpanel.com' og 'api- decide.mixpanel.com', så svigt detekteres automatisk snarere end via kunderapporter. * * * Hostname audit: * * Vi reviderer alle offentlige API værtsnavne og routing aliases for lignende udokumenterede indgangspunkter, og vi vil gennemgå nye værtsnavne og aliaser, før de går live. Vi sporer også trafik, der ankommer på ethvert uventet værtsnavn. * * * Sikker flytning: * * Før nogen fremtidig ændring til et offentligt værtsnavn, vil vi bekræfte nul trafik på værtsnavnsniveau, og vi vil identificere og kontakte alle projekter, der stadig bruger det. * * * Kundekommunikation: * * Vi vil give kunderne forhåndsmeddelelse om væsentlige infrastrukturændringer, der påvirker offentlige værtsnavne, herunder offentliggøre dem på en tidslinje i vores changelog. * * Allerede indsat: * * * Gendannet 'decide.mixpanel.com' og 'api- decide.mixpanel.com.' * '/ beslutte' forbliver pensioneret # # # # * Fælles spørgsmål * * * * * blev mine data påvirket? * * Kun hvis din SDK eller proxy sendte anmodninger til 'decide.mixpanel.com' eller 'api- decide.mixpanel.com' mellem 15. oktober og 21. oktober. Der blev ikke modtaget data i dette vindue, som ikke kan genoprettes af Mixpanel. Hvis du beholdt en kopi af disse data, kan du sende den tilbage til Mixpanel ved hjælp af vores Ingestion API endepunkter såsom '/ import' for begivenheder. Skal jeg ændre noget? Nej, domænerne virker igen. Vi anbefaler at bruge 'api.mixpanel.com'\ (eller 'api- eu.mixpanel.com' / 'api- in.mixpanel.com' for EU og Indien data residency\) som dit API domæne. * * er * * '/ beslutte' kommer tilbage? Nej. Det forbliver pensioneret som annonceret, og det er adskilt fra 'decide.mixpanel.com' værtsnavn. Vi beklager forstyrrelsen. Hvis du har spørgsmål om dit projekt, bedes du kontakte dit kontohold eller Mixpanel Support.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 8. oktober 2026 kl. 16.32 UTCinvestigating

   Vi oplever i øjeblikket forsinkelser i vores data indtagelse rørledning, som påvirker realtidsdata for projekter, der er indskrevet i de amerikanske projekter, hvilket resulterer i forsinkelser for en delmængde af projekter. Mens ingen data går tabt, undersøger vores ingeniørhold aktivt sagen og arbejder på at genoprette realtidsfunktionalitet så hurtigt som muligt. Vi sætter pris på din tålmodighed i denne tid. Hvis du har spørgsmål, bedes du kontakte support.

2. 8. oktober 2026 kl. 17.32 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 8. oktober 2026 kl. 18.31 UTCidentified

   Vi har identificeret årsagen til den indtagelse forsinkelse som et opstrøms problem med vores cloud storage udbyder, Google Cloud, påvirker en delmængde af amerikanske projekter. Google har bekræftet dette som et højt prioriteret spørgsmål i deres ende, men har ikke givet en ETA endnu. Vi har foretaget afbødninger for at sikre en jævn bedring, når den er ryddet. Ingen begivenheder går tabt. Dette er strengt en indtagelse forsinkelse, vil alle berørte data fortsat blive genbehandlet, når problemet er løst.

4. 8. oktober 2026 kl. 19.30 UTCmonitoring

   Vores målinger viser, at indtagelse er indhentet og ikke længere oplever forsinkelse. Google har endnu ikke bekræftet løsning af det underliggende opstrømsproblem på deres ende, så vi fortsætter med at overvåge tæt i tilfælde af gentagelse.

5. 8. oktober 2026 kl. 21.30 UTCmonitoring

   Ingen ændringer siden vores seneste opdatering, vi fortsætter med at observere ingen aktiv indtagelse forsinkelse på vores ende, og alle systemer forbliver sunde. Vi fortsætter med at overvåge nøje.

6. 8. oktober 2026 kl. 22.30 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

7. 8. oktober 2026 kl. 23.30 UTCmonitoring

   Systemerne er forblevet stabile, uden at indtagelsen er forsinket igen. Vi holder nøje øje med tingene, mens vi venter på den endelige bekræftelse fra vores leverandør.

8. 9. oktober 2026 kl. 00.22 UTCresolved

   Denne hændelse er blevet løst. Den opstrøms problem med vores cloud storage udbyder er blevet rettet, og vores indtagelse rørledning har fungeret normalt uden aktive forsinkelser. Ingen hændelser blev tabt under denne hændelse, alle berørte data blev fuldt genbehandlet. Tak for Deres tålmodighed under denne hændelse.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 26. august 2026 kl. 21.39 UTCinvestigating

   Mixpanel oplever forringet Query API ydeevne, hvilket resulterer i HTTP 500 svar, når du spørger rapporter til projekter med US Data Residency. Projekter med EU og IN Data Residency forbliver uberørt. Vi sætter pris på din tålmodighed, mens vores ingeniører arbejder på at genoprette normal funktionalitet. Vi vil sende statusopdateringer på vores statusside. Hvis du har spørgsmål, bedes du kontakte support.

2. 26. august 2026 kl. 22.11 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 26. august 2026 kl. 22.28 UTCmonitoring

   En rettelse er blevet implementeret, og vi ser forbedrede succesrater for Query API. Vi vil fortsat overvåge for at sikre stabilitet.

4. 26. august 2026 kl. 22.45 UTCresolved

   Denne hændelse er blevet løst.

5. 8. september 2026 kl. 18.25 UTCpostmortem

   # Mixpanel RCA: Midlertidig forespørgsel Service Afbrydelse for amerikanske projekter 26 August 2026 # Summary Mellem ca. * * 2: 02 PM og 3: 19 PM PT den 26 august 2026 * *, projekter i den amerikanske region oplevede fejl indlæsning rapporter og kører forespørgsler gennem Mixpanel UI og Query API. Under dette vindue, nogle forespørgsler i regionen mislykkedes eller returnerede fejl. * * Ingen kundedata blev tabt, og data indtagelse blev ikke påvirket. * * Alle begivenheder fortsatte med at blive indsamlet og gemt normalt i løbet af hændelsen; når forespørgsel service blev genoprettet, alle rapporter afspejlede komplette, nøjagtige data uden kundens handling kræves. Årsagen blev identificeret som et nyligt anvendt internt værktøj til diagnostisk forespørgsel replay, en evne vores ingeniører bruger til at genkøre kopier af tidligere forespørgsler til debug ydeevne, som uventet skrev store mængder af data til disketter af vores forespørgsel servere, forbrugende lagerkapacitet serverne har brug for at operere. Når disse diske fyldt, de berørte servere tog sig ud af tjenesten. Service blev genoprettet, de ramte servere blev bragt tilbage online, og det interne værktøj var deaktiveret. De oprensninger nedenfor tilføje opbevaring sikkerhedsforanstaltninger for at fjerne interne værktøjer evne til at forbruge ressourcer på forespørgselsservere, og er designet til at forhindre denne klasse af fiasko sker igen i fremtiden. Hvad skete der? Mixpanel forespørgsel motor kører på en flåde af servere, der hver bruger et sæt af lokale lagervolumener til cache de data, der er nødvendige for at besvare forespørgsler hurtigt. Separately, vores ingeniører bruger diagnostisk forespørgsel replay værktøj, en evne vores ingeniører bruger til at reproducere og debug forespørgsel ydeevne. Mens du anvender den diagnostiske forespørgsel replay værktøj til en stor, kompleks forespørgsel, en software bug forårsaget forespørgslen replay fanger til fan ud på tværs af hele flåden i stedet for at forblive begrænset til en enkelt server. Derudover forårsagede det langt flere data end beregnet til at blive gemt uden rettidig udsættelse på en enkelt server. To faktorer så udvidet virkningen af spørgsmålet: * En enkelt fuld lagervolumen tog en server helt ude af drift. Hver server behandler sin cache som usund, hvis en af dens lagervolumener krydser en anvendelse tærskel, selv når alle andre mængder er sunde. Replay data blev skrevet til en bestemt volumen på hver server, så servere i hele regionen mislykkedes deres sundhedstjek næsten samtidigt. * Cleanup grænser ikke tage højde for datastørrelse. Beskyttelsen begrænser replay data på disk talte elementer på applikationsniveau snarere end bytes på filsystem niveau, så et lille antal uventet store captures bestået kontrollen, mens forbruge det meste af volumen kapacitet. Tilsammen tillod disse en enkelt fejlsøgning workflow, der normalt har en ubetydelig fodaftryk til at afbryde produktionen forespørgsel tjener i hele den amerikanske region. Tidslinje\ (Pacific Time, 26 August, 2026\) * * * 2: 00 PM * * - Første overdimensionerede diagnostisk genspil capture blev skrevet; lagervolumen begyndte at nå deres kapacitet og forespørgsel succesrate begyndte at falde kort efter. * * * 2: 17 PM * * - Automatiseret alarmering tilkaldte on- call ingeniør; undersøgelse begyndte straks og yderligere ingeniører blev engageret. * * * 2: 39 PM * * - Status side hændelse lagt; in-app banner vises på 2: 40 PM. * * * 2: 53 PM * * - Root årsag identificeret; recovery indsats begyndte på den første berørte server gruppe. * * * 3: 19 PM * * - Forespørgsel service genoprettet for langt størstedelen af trafikken; den endelige server gruppe fuldt genvundet på 3: 27 PM. * * * 3: 45 PM * * - Tilfælde løst efter en stabil observationsperiode. Den diagnostiske replay værktøj, der udløste problemet var fuldt deaktiveret samme aften. "Root cause 1. * * En software fejl i vores forespørgsel replay værktøj forårsaget ubegrænsede skriver til produktion opbevaring. * * En nylig indsat evne til at reproducere forespørgsler mishandled en bestemt klasse af komplekse forespørgsel, forårsager fangster til at sprede sig til hver forespørgsel server i regionen og til at skrive langt flere data til de berørte mængder, end designet antages. 2. * * Genafspil filer forbrugt diskkapacitet, som forespørgsel servering afhænger af. * * Replay tooling skrev sine filer til forespørgslen servers 'lokale diske, så runaway replay data opbrugt lagerkapacitet serverne har brug for at besvare forespørgsler. 3. * * Beskyttelsesforanstaltninger tegnede sig kun delvist for adfærden. * * Den oprydning politik for diagnostiske replay data begrænset antallet af elementer på disken, men ikke deres samlede størrelse, så det ikke engagere sig. Alerting på lagervolumen markeret væksten, men var ikke eskaleret som kritisk på en per- server basis, som forsinket påvisning indtil forespørgsel fejl begyndte. "What we 're changing Sluttilstanden vi bygger mod: interne diagnostiske forespørgsel replay data gemt i dedikeret objekt opbevaring, placere ingen belastning på produktionen forespørgsel servere. Allerede indsat: * * * Deaktiveret det interne værktøj * *, der forårsagede hændelsen, og oprydning af den underliggende problem, så diagnostiske optagelser er begrænset til en enkelt server og den specifikke forespørgsel klasse håndteres korrekt. * * * Documented the target recovery procedure * * anvendes i løbet af hændelsen, dvs., rydde kun den berørte lagervolumen i stedet for at genstarte fuld server grupper, i vores operationelle runbooks, afkorte recovery tid, hvis nogen volumen kapacitet løber ud i fremtiden. I øjeblikket: * * * Filsystem-niveau, baseret grænser på diagnostiske replay data * *, capping total bytes på disk snarere end element tæller, så overdimensionerede captures afvises eller udskydes, før de kan påvirke volumen kapacitet. * * * Strengere opbevaring advarsel * *, eskalerende per- server volumen mætning som kritisk, før det kan påvirke forespørgsel sundhedstjek. * * * Flytning forespørgsel replay data til dedikeret objekt opbevaring, * * så det bruger ingen ressourcer på produktionen forespørgsel servere. "Common questions * * * blev nogen data tabt? * * No. Data indtagelse var upåvirket under hele hændelsen: begivenheder fortsatte med at blive indsamlet, i kø, og opbevares normalt. Kun evnen til at spørge blev afbrudt. Når tjenesten blev genoprettet, alle rapporter afspejlede fuldstændige data. * * blev gemt rapporter, dashboards eller projektindstillinger påvirket? * * Nej. Hændelsen påvirket forespørgsel udførelse kun. Intet i dit projekt ændrede sig. * * * Hvorfor påvirkede det flere amerikanske projekter på én gang? * * De overdimensionerede diagnostiske replay data skrevet til hver forespørgsel servers diske på næsten samme tid, og hver server fjerner sig fra service, når en enkelt volumen fylder. Forebyggelse af internt værktøj fra forbrugende query- server opbevaring er en central del af vores oprydning arbejde. * * * Hvordan forhindrer det fremskridt? * * Værktøjsproblemet er løst, og værktøjet forbliver deaktiveret, indtil der er fastsat målgrænser. Opbevaring alarmering bliver strammet så mætning er fanget, før det påvirker forespørgsel servering. Strukturelt, vi flytter diagnostiske data off produktionen forespørgsel servere helt, så interne debugging data vil forbruge ingen lagring på de servere, der er ansvarlige for forespørgsler behandling. Vi undskylder forstyrrelsen, og tidsrapporterne var ikke tilgængelige. Kontakt venligst din konto eller support med spørgsmål.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 19. august 2026 kl. 23.20 UTCidentified

   Vi oplever i øjeblikket problemer med at befolke begivenhedsegenskaber i dropdown menuer. Vi sætter pris på din tålmodighed, mens vores ingeniører arbejder på at genoprette funktionalitet. Hvis du har spørgsmål, bedes du kontakte support @ mixpanel.com

2. 20. august 2026 kl. 01.04 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

3. 20. august 2026 kl. 02.52 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 20. august 2026 kl. 03.05 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. august 2026 kl. 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 kl. 08.39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 6. august 2026 kl. 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 kl. 13.32 UTCresolved

   This incident has been resolved.

1. 22. juli 2026 kl. 08.03 UTCinvestigating

   Vi oplever i øjeblikket problemer med Mixpanel agenten i webappen. Vores ingeniørhold er blevet advaret og undersøger problemet og arbejder på at genoprette dets funktionalitet. Vi sætter pris på Deres tålmodighed, når vi arbejder på at løse dette problem. Hvis du har spørgsmål, bedes du kontakte support.

2. 22. juli 2026 kl. 09.52 UTCinvestigating

   teamet fortsætter med at undersøge spørgsmålet og næste skridt. Tak for din tålmodighed.

3. 22. juli 2026 kl. 10.55 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 22. juli 2026 kl. 14.47 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 11. juli 2026 kl. 07.53 UTCinvestigating

   Vi oplever i øjeblikket forsinkelser i vores data indtagelse rørledning, som påvirker realtidsdata for projekter, der er indskrevet i de amerikanske projekter, hvilket resulterer i forsinkelser for en delmængde af projekter. Mens ingen data går tabt, undersøger vores ingeniørhold aktivt sagen og arbejder på at genoprette realtidsfunktionalitet så hurtigt som muligt. Vi sætter pris på din tålmodighed i denne tid. Hvis du har spørgsmål, bedes du kontakte support.

2. 11. juli 2026 kl. 09.17 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 11. juli 2026 kl. 10.15 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

4. 11. juli 2026 kl. 12.54 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

5. 11. juli 2026 kl. 14.25 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

6. 11. juli 2026 kl. 15.54 UTCresolved

   Denne hændelse er blevet løst.

7. 16. juli 2026 kl. 23.47 UTCpostmortem

   # Summary Mellem ca. * * 11: 35 PM PT den 10. juli og 7: 19 AM PT den 11. juli 2026 * *, data indtagelse for Mixpanel projekter i den amerikanske region løb bagud med op til ~ 2 timer. I dette vindue, rapporter og dashboards midlertidigt viste ufuldstændige data - seneste tidsintervaller kunne vises som skarpe, kunstige dråber i målinger såsom aktive brugere eller indtægter. * * Ingen data gik tabt. * * Alle begivenheder blev i kø permanent og behandles i fuld, når backloggen ryddet; målinger returneres til nøjagtige værdier på egen hånd, uden at kunden handling kræves. Årsagen opstod i vores indtagelse kontrol: for et lille antal meget højt volumen projekter, den indtagelse, vi tillod, havde drevet ud af tilpasning med kapaciteten til disse projekter. Stor historisk import - helt legitimt brug af platformen - blev derfor indrømmet hurtigere, end deres infrastruktur kunne absorbere, og to egenskaber ved vores rørledning vendte den lokale overbelastning til en regional-bred forsinkelse. Nedenstående rettelser reign disse kontroller, således at enhver import, af enhver størrelse, automatisk holdes inden for sikre grænser. Hvad skete der? Mixpanel "s indtagelse rørledning er skægget og multi-lejer: hvert projekt data er fordelt på et sæt af partitioner størrelse for sin forventede volumen, og for gennemløb, er begivenheder fra mange kunder behandles sammen i partier. Dette design giver høj effektivitet, men det afhænger af en invariant: den hastighed, hvormed vi indrømmer et projekts trafik skal matche den kapacitet, der er afsat til det. Når denne invariant holder, selv meget stor import absorberes problemfrit. Her holdt den ikke. Et lille antal meget store historiske data import kørte på projekter, hvis tilladte indtagelse var med tiden vokset langt ud over deres hensatte fordelingskapacitet. Den overskydende volumen koncentreret på specifikke partitioner som * * hot spots * *, mætte den del af streaming flåde tjener dem. To faktorer så udvidet virkningen: * * * Bundet, multi-lejer forarbejdning forstærket hot spots. * * Fordi begivenheder fra mange kunder rejser sammen i partier, langsommelighed og fejl på de overbelastede partitioner forsinkede uafhængige kunders arrangementer, der delte disse partier. * * * Automatisk scene- up var ineffektiv. * * Tilføjelse af kapacitet kan ikke opløse et hot spot af denne art, fordi de overbelastede partitioner forbliver fastgjort til samme infrastruktur, og en kapacitetsgrænse i en komponent af vores streaming infrastruktur forhindrede den ekstra kapacitet i at få virkning. Sammen blev det, der skulle have været en kort, selvhelbredende afmatning, til en forsinkelse på flere timer, der krævede manuel indgriben. # Timeline\ (Pacific Time, Juli 10-11\) * * * 11: 35 PM * * - Automatiseret alarmering opdaget indtagelse backlog; on- call ingeniør aktiveret med det samme. * * 12: 49 AM * * - Status side hændelse bogført; indslag scoped til den amerikanske region kun. * * * 1: 23 AM * * - Den største bidragende import blev sat på pause. * * 1: 55- 6: 48 AM * * - Progressive lempelser: yderligere trafikkilder væltet, visse backloged data udskudt med ejerens aftale, svigt isolation aktiveret i rørledningen, og berørte infrastrukturknudepunkter erstattet. * * 7: 19 AM * * - Backlog fuldt behandlet; alle projekter aktuelle. Status side flyttet til overvågning, derefter løst efter en stabil observationsperiode. "Root cause 1. * * Indtagningshastighed grænser forkert tilpasset den reserverede kapacitet. * * For de drivende projekter, de satser vores platform indrømmede var vokset ud af trit med den infrastruktur, der er afsat til dem, så legitime høj-volumen import blev lukket ind hurtigere, end deres partitioner kunne absorbere. Dette er den systemiske rod årsag. Selve importen var en legitim anvendelse af platformen. 2. * * Bundet, multi-lejer forarbejdning forstærket overbelastning. * * Fejl på de overbelastede partitioner forsinkede uafhængige kunders arrangementer, der deler de samme behandlingsbatcher, og spredte et lokaliseret problem på tværs af platformen. 3. * * Trafik til de overbelastede partitioner kunne ikke omfordeles. * * Partition- to- server opgave i streaming-laget var ikke load- opmærksomme, så hot spots forblev fastgjort til de samme servere uanset flådens størrelse - den samlede kapacitet var tilstrækkelig, men det kunne ikke bringes til at bære. En skalering grænse i en komponent af vores streaming infrastruktur yderligere dette ved at forhindre scale-up fra at tilføje kapacitet, som forsinkede diagnosen indtil ingeniører greb manuelt ind. "What we 're changing Den endelige tilstand, vi bygger mod: * * hvert projekt "s indtagelse grænser automatisk matche sin provied kapacitet, således at import af enhver størrelse, herunder fuld historiske backfills og data lagersyncs, kan køre uden forudgående koordinering, og et projekts volumen er forhindret i at påvirke en andens data friskhed. * *. Allerede indsat - forbedre vores indtagelse håndtering: * * * Forbedret håndtering af hotspot. * * Trafikfordelingen i streaming-laget er nu belastet-bevidst, spredning af koncentreret belastning mere jævnt over hele flåden, og enkelte problempunkter er nu genafprøvet separat i stedet for at holde op resten af deres parti - reducere, men ikke eliminere, den indvirkning en lokaliseret overbelastning kan have på ikke-relateret trafik. * * * Udlejning af de højeste arbejdsbelastninger * * til infrastruktur af passende størrelse, prioriteret efter risiko. Allerede indsat - ændre hvordan vi driver tredje part streaming service: * * * Revideret og reafstemt flådens kapacitetsprofil * * så individuelle servere har betydeligt mere headroom for koncentreret belastning, og arbejdede med udbyderen for at løse skalering begrænsning stødt under hændelsen. I øjeblikket: * * * Kapacitets- bevidst hastighedsbegrænsning * * - at lukke hullerne mellem individuelt tildelte projektgrænser og hvert projekts reelle udbudskapacitet, udvide hastighedsbegrænsning til indsugningsveje, der tidligere manglede det, og forbinde eventuelle fremtidige grænser stigning til en kapacitetsstigning, som er designet til at forhindre denne klasse af misorientering fra tilbagevendende.. * * * Finer- graden volumen overvågning og advarsel * * så kapacitet fejljustering detekteres og rettes, før det kan påvirke nogen kunde. * Vurdering af stærkere arbejdsbyrde isolation / tilbage-log opsving prioritering for bulk / backfill trafikveje, så historisk import har reduceret indvirkning på levende trafik "Common questions * * * blev nogen data tabt? * * Nej. Begivenheder blev varigt i kø under hele hændelsen og blev fuldt behandlet, når backlog ryddet. Eventuelle metriske dråber set under vinduet var et display artefakt af forsinkelsen og selvkorrigeret. * * * Skal jeg koordinere stor import eller backfills med Mixpanel? * * Nej. Vores mål er, at platformen til at holde enhver import inden for sikre priser automatisk, så backfills og lagersyncs kan køre uden planlægning eller varsel. Vi er stadig ved at udrulle den kapacitet-bevidste kontrol, der leverer dette. I mellemtiden, hvis du planlægger en usædvanlig stor import eller backfill, anbefaler vi koordinering med din konto team, så vi kan bekræfte kapacitet på forhånd. * * * Hvordan forhindrer det fremskridt? * * Den systemiske fix er at stramme hullerne mellem individuelt tildelte projektrater og hvert projekts reelle udbudskapacitet, og udvide hastigheden begrænser sig til de indsugningsveje, der tidligere manglede det - så overbelastning af denne type er stoppet ved optagelse. Desuden er den begrænsning, som forlængede hændelsen, der er fastsat, rørledningen nu relancere individuelle problempunkter separat, så en lokaliseret overbelastning har langt mindre indvirkning på ikke-relateret trafik, og bulk trafik er yderligere isoleret fra levende trafik. * * * Kan individuelle projekter prioriteres under opsvinget? * * Denne kapacitet eksisterede ikke under hændelsen - alle projekter inddrives med samme hastighed. Vi er i færd med at evaluere prioriteringsmekanismerne for tilbagesøgning som en del af vores opfølgningsarbejde. Vi undskylder forstyrrelsen og den bekymring, de midlertidigt deprimerede målinger forårsagede. Kontakt venligst din konto eller support med spørgsmål.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. juni 2026 kl. 19.47 UTCinvestigating

   Mixpanel oplever forringet ydeevne med vores Query API, herunder øget latency. Du kan se langsom-loading rapporter eller forespørgsel fejl. Vi sætter pris på din tålmodighed, mens vores ingeniører arbejder på at genoprette normal funktionalitet. Vi vil sende statusopdateringer på vores statusside. Hvis du har spørgsmål, bedes du kontakte support.

2. 29. juni 2026 kl. 21.04 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 29. juni 2026 kl. 22.42 UTCidentified

   Query latency har stabiliseret sig, selvom vores team fortsætter med at undersøge den underliggende årsag til den forringede ydeevne. Vi vil fortsætte med at sende opdateringer som vores undersøgelse skrider frem. Tak for din tålmodighed.

4. 30. juni 2026 kl. 02.15 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

5. 30. juni 2026 kl. 03.30 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 3. juni 2026 kl. 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 kl. 20.17 UTCidentified

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

3. 3. juni 2026 kl. 21.27 UTCresolved

   This incident has been resolved.

1. 2. juni 2026 kl. 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 kl. 12.31 UTCidentified

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

3. 2. juni 2026 kl. 14.31 UTCmonitoring

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

4. 2. juni 2026 kl. 16.53 UTCresolved

   This incident has been resolved.

1. 1. juni 2026 kl. 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 kl. 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 kl. 15.29 UTCidentified

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

4. 1. juni 2026 kl. 16.38 UTCmonitoring

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

5. 1. juni 2026 kl. 19.42 UTCresolved

   This incident has been resolved.

1. 19. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 20.23 UTCmonitoring

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

4. 19. maj 2026 kl. 21.18 UTCresolved

   This incident has been resolved.

1. 14. maj 2026 kl. 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. maj 2026 kl. 23.48 UTCidentified

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

3. 15. maj 2026 kl. 10.19 UTCidentified

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

4. 15. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 21.23 UTCidentified

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

10. 15. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 01.52 UTCmonitoring

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

13. 16. maj 2026 kl. 02.50 UTCresolved

    This incident has been resolved.

14. 21. maj 2026 kl. 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. maj 2026 kl. 16.34 UTCidentified

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

2. 13. maj 2026 kl. 21.40 UTCidentified

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

3. 14. maj 2026 kl. 13.35 UTCresolved

   This incident has been resolved.

1. 12. maj 2026 kl. 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. maj 2026 kl. 17.46 UTCidentified

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

3. 12. maj 2026 kl. 20.24 UTCmonitoring

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

4. 12. maj 2026 kl. 21.44 UTCresolved

   This incident has been resolved.

1. 6. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 20.04 UTCresolved

   This incident has been resolved.

1. 9. april 2026 kl. 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 kl. 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 kl. 21.44 UTCresolved

   This incident has been resolved.

1. 16. marts 2026 kl. 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. marts 2026 kl. 19.29 UTCmonitoring

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

3. 16. marts 2026 kl. 21.47 UTCresolved

   This incident has been resolved.

1. 2. marts 2026 kl. 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. marts 2026 kl. 21.09 UTCidentified

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

3. 2. marts 2026 kl. 21.09 UTCmonitoring

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

4. 2. marts 2026 kl. 21.53 UTCresolved

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