Degraded Service for Requests to decide.mixpanel.com
A început 21 octombrie 2026 la 18:04 UTC · 2h 11m
Pending
monitoring
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.
resolved
This incident has been resolved.
Degradat Service pentru cereri de decizie.mixpanel.com
A început 21 octombrie 2026 la 18:00 UTC · 7h 33m
Pending
monitoring
Am primit rapoarte că cererile de a decide.mixpanel.com nu reuşesc.
Orice trafic trimis prin decide.mixpanel.com poate fi afectat, inclusiv steaguri caracteristică și de urmărire a evenimentelor.
Pentru a restabili serviciul acum, solicitaţi puncte la api.mixpanel.com (US), api-eu.mixpanel.com (EU), sau api-in.mixpanel.com (IN), în funcţie de rezidenţa datelor proiectului dumneavoastră.
Am lansat o atenuare şi monitorizăm rezultatele. Vedem traficul restaurat.
Vom posta actualizări de progres pe pagina noastră de stare.
Dacă aveți întrebări, vă rugăm să contactați sprijinul.
resolved
Acest incident a fost rezolvat.
postmortem
# **Mixpanel RCA: Requests to** [**decide.mixpanel.com**](http://decide.mixpanel.com) **Failed, Octombrie 15
###**Summary**
De la 15 octombrie 2026 până la 21 octombrie 2026, cererile trimise la
Acest lucru a afectat clienții care au trimis de urmărire evenimente, actualizări de profil, sau cereri de pavilion caracteristică la acest nume gazdă, de obicei, printr-un proxy.
Evenimentele trimise în acest domeniu în timpul acestei ferestre nu au fost primite de Mixpanel, iar aceste date nu pot fi restaurate de Mixpanel.
**Traffic trimis la**
Serviciul pe acest nume de gazdă a fost neintenţionat afectate în timp ce am fost eliminarea infrastructurii de evaluare a obiectivelor de bază. Numele gazdelor au fost tratate ca parte a obiectivului datorită unei înțelegeri incorecte a dependențelor sistemului. Pentru a preveni această clasă de emisiuni, adăugăm monitorizarea traficului pentru numele gazdelor.mixpanel.com și "api-decide.mixpanel.com." De asemenea, vom solicita confirmarea traficului zero la nivelul numelui gazdei înainte ca numele gazdei să fie eliminat.
**We have became reinstaurat service on**
Ce s-a întâmplat?
Older Mixpanel SDKs a numit punctul final de referință pentru a prelua configurația pentru [**Legacy Automat tracked Mobile Events**](https://docs.mixpanel.com/docs/traking-methods/sdks/ios#legacy-automat-tracked-evenimente). Noi [anunțat obiectivul de bază se pensionează](https://docs.mixpanel.com/changelogs#2026-01-26), și pentru o anumită perioadă de timp
Separat, De exemplu, Unii clienți au înființat proxies sau configurații SDK pentru a trimite traficul lor la aceste nume gazdă.
Pe 15 octombrie la 7:40 PM CDT, în timpul curățării finale a finalului de evaluare
Înainte de a face această schimbare, am confirmat că traficul către punctul final de evaluare a fost redus la zero. Cu toate acestea, monitorizarea traficului măsurat în funcție de criteriul final, mai degrabă decât de numele gazdei. Prin urmare, nu s-a demonstrat că alte cereri, cum ar fi
De atunci înainte, toate cererile la acest nume de gazdă nu a reușit, inclusiv obiectivele finale, cum ar fi
* **Evenimente și profiluri:** Evenimente, Profile și orice date destinate [Ingestia API finals] [https://docs.mixpanel.com/reference/ingestion-api] acestor nume de gazdă în timpul acestei ferestre nu au ajuns niciodată la Mixpanel, astfel încât nu avem o copie pentru a restabili. Dacă ați păstrat aceste date în altă parte, cum ar fi jurnalele proxy sau depozitul de date, le puteți re-trimite către API-uri Ingestion [/import](https://docs.mixpanel.com/reference/import-events), [/angage,](https://docs.mixpanel.com/reference/profil-set) și [/grups](https://docs.mixpanel.com/reference/group-set-property).
* ** Indicatoare feature:** Solicitările de pavilion ale caracteristicilor trimise acestor nume de gazdă au eșuat. SDK-urile au servit ultima variantă stocată în cazul în care există una sau în caz contrar valoarea de rezervă configurată în codul dumneavoastră.
Traducerea şi adaptarea:
* ** 15 octombrie, ora 7:40 PM CDT:** Se aplică îndepărtarea numelui gazdei. Solicitări de a decide.mixpanel.com și
* **16 octombrie 5:22 AM CDT:** Primim primul raport al clientului. Inițial, se înțelege că este legată de pensionarea planificată.
* ** 21 octombrie, 11:42 AM CDT:** În urma unei creșteri a rapoartelor clienților cu privire la urmărirea eșecului pentru proxy-uri, identificăm îndepărtarea numelui gazdei ca fiind cauza.
* ** 21 octombrie, 12:26 PM CDT:** Refacem numele gazdelor.
* ** 21 octombrie, 1:51 PM CDT:** Confirmăm traficul către numele de gazdă restaurate a recuperat.
* ** 21 octombrie, 8:34 PM CDT:** Incidentul este rezolvat.
Cauza Root
1. În timpul pensionării/decidei de pensionare, s-au eliminat neintenţionat.mixpanel.com şi اapi-decide.mixpanel.com.
2. Aceste nume de gazde au fost configurate pentru a accepta toate API trafic, nu numai cereri, şi acest comportament a fost nedocumentat.
3. Monitorizarea noastră a urmărit traficul până la punctul final de bază
4. Deoarece numele gazdelor și criteriul final retras împărtășesc un nume, rapoartele timpurii ale clienților au fost interpretate inițial ca fiind efectele preconizate ale pensionării anunțate/decide. Această creştere întârziată.
Ce ne schimbăm
* **Monitoring and alerting:** Adăugăm monitorizarea traficului și rata de eroare și alertarea pentru
* **Hostname audit:** Audităm toate numele de gazdă ale API-ului public și rutam pseudonime pentru puncte de intrare nedocumentate similare, și vom revizui noi nume de gazdă și pseudonime înainte de a merge în direct. Urmărim, de asemenea, traficul care ajunge pe orice nume de gazdă neașteptat.
* ** Îndepărtarea saferului:** Înainte de orice schimbare viitoare la un nume de gazdă publică, vom confirma traficul zero la nivelul numelui gazdei, și vom identifica și contacta orice proiecte încă folosind-o.
* ** Comunicarea clienţilor:** Vom anunţa clienţii în prealabil cu privire la schimbările de infrastructură materială care afectează numele gazdelor publice, inclusiv publicarea acestora pe un calendar în jurnalul nostru de schimb.
**Deja desfăşurat:**
* Restored
*
Întrebări comune
Datele mele au fost afectate? Numai în cazul în care SDK sau proxy dvs. a trimis cereri pentru a Datele trimise acolo în timpul acelei ferestre nu au fost primite și nu pot fi restaurate de Mixpanel. Dacă ați păstrat o copie a acestor date, puteți re-trimite să Mixpanel folosind criteriile noastre de evaluare a Ingestia API, cum ar fi
Trebuie să schimb ceva? Nu, domeniile lucrează din nou. Vă recomandăm să utilizaţi
* ** Este** Nu. Acesta rămâne retras așa cum s-a anunțat, și este separat de numele gazdei.mixpanel.com.
Ne pare rău pentru întrerupere. Dacă aveţi întrebări despre proiectul dumneavoastră, vă rugăm să contactaţi echipa de cont sau Mixpanel Support.
Traducere automată din actualizarea oficială a incidentului.
Întârziere temporară a datelor pentru proiectele din SUA
A început 8 octombrie 2026 la 16:32 UTC · 7h 50m
Pending
investigating
În prezent, ne confruntăm cu întârzieri în conducta noastră de ingerare a datelor, care afectează datele în timp real pentru proiectele înscrise în proiectele din SUA, ceea ce duce la întârzieri pentru un subset de proiecte. Deși nu se pierd date, echipa noastră de inginerie investighează în mod activ problema și lucrează pentru a restabili funcționalitatea în timp real cât mai repede posibil. Îţi apreciem răbdarea în acest timp.
Dacă aveți întrebări, vă rugăm să contactați sprijinul.
identified
Problema a fost identificată și se pune în aplicare o soluție.
identified
Am identificat cauza întârzierii ingestiei ca o problemă în amonte cu furnizorul nostru de stocare cloud, Google Cloud, care a afectat un subset de proiecte americane. Google a confirmat acest lucru ca o problemă de înaltă prioritate la sfârșitul lor, dar nu a furnizat încă un ETA. Am implementat măsuri de atenuare pentru a asigura o recuperare fără probleme, odată ce se vindecă.
Nu se pierd evenimente. Aceasta este strict o întârziere a ingestiei, toate datele afectate vor continua să fie reprocesate după rezolvarea problemei.
monitoring
Parametrii noştri arată că ingestiea este prinsă şi nu se mai confruntă cu întârzieri. Google nu a confirmat încă soluționarea problemei subiacente din amonte la sfârșitul lor, așa că noi continuăm să monitorizăm îndeaproape în caz de recurență.
monitoring
Nici o schimbare de la ultima noastră actualizare, continuăm să observăm nici o întârziere de ingestie activă la sfârșitul nostru, și toate sistemele rămân sănătoase. Continuăm să monitorizăm îndeaproape.
monitoring
Continuăm să monitorizăm orice alte probleme.
monitoring
Sistemele au rămas stabile, fără repetarea întârzierii ingestiei. Suntem cu ochii pe lucruri în timp ce așteptăm confirmarea finală de la furnizorul nostru în amonte.
resolved
Acest incident a fost rezolvat. Problema din amonte cu furnizorul nostru de stocare a cloudului a fost reparată, iar conducta noastră de ingestie funcţionează normal fără întârzieri active. Nu s-au pierdut evenimente pe parcursul acestui incident, toate datele afectate au fost reprocesate complet.
Vă mulţumesc pentru răbdare pe parcursul acestui incident.
Traducere automată din actualizarea oficială a incidentului.
Query Degradat API Performance impact US Proiecte
A început 26 august 2026 la 21:39 UTC · 1h 7m
OutageIncident major
Componente afectate
Application Availability (US)
investigating
Mixpanel se confruntă cu o performanță de Query API degradată, rezultând răspunsuri HTTP 500 atunci când interogarea rapoartelor pentru proiecte cu RESidency de date SUA. Proiectele UE și IN Data Residency rămân neafectate.
Apreciem răbdarea dumneavoastră în timp ce inginerii noștri lucrează pentru a restabili funcționalitatea normală. Vom posta actualizări de progres pe pagina noastră de stare.
Dacă aveți întrebări, vă rugăm să contactați sprijinul.
identified
Problema a fost identificată și se pune în aplicare o soluție.
monitoring
Un fix a fost implementat, și vedem rate de succes îmbunătățite pentru API Query. Vom continua monitorizarea pentru a asigura stabilitatea.
resolved
Acest incident a fost rezolvat.
postmortem
Mixpanel RCA: Serviciul de interogare temporară disrupţie pentru proiectele SUA 26 august 2026
Sumarul
Între aproximativ **2:02 PM și 3:19 PM PT pe 26 august 2026**, proiectele din regiunea SUA au experimentat rapoarte de încărcare a defecțiunilor și au rulat întrebări prin intermediul Mixpanel UI și Query API. În timpul acestei ferestre, unele întrebări din regiune au eșuat sau au returnat erori. **Nu s- au pierdut date despre clienţi, iar ingerarea datelor nu a fost afectată.** Toate evenimentele au continuat să fie colectate și stocate în mod normal de-a lungul incidentului; odată ce serviciul de interogare a fost restaurat, toate rapoartele au reflectat date complete și exacte, fără nicio acțiune a clientului necesară.
Cauza a fost identificată ca un instrument intern recent implementat pentru reluarea interogării diagnostice, o capacitate pe care inginerii noștri o folosesc pentru a rerula copii ale interogărilor anterioare pentru a depana performanța, care a scris în mod neașteptat cantități mari de date pe discurile serverelor noastre de interogare, consumând capacitatea de stocare necesară pentru funcționarea serverelor. Când acele discuri s-au umplut, serverele afectate s-au scos din funcţiune. Serviciul a fost restaurat, serverele afectate au fost readuse online, iar sculele interne au fost dezactivate. Remedierile de mai jos adaugă garanții de stocare pentru a elimina capacitatea instrumentare internă de a consuma resurse pe servere de interogare, și sunt concepute pentru a preveni această clasă de eșec să se întâmple din nou în viitor.
Ce s-a întâmplat
Motorul de interogare Mixpanel rulează pe o flotă de servere care folosesc fiecare un set de volume de stocare locale pentru a stoca datele necesare pentru a răspunde rapid la întrebări. Separat, inginerii nostri folosesc replay-ul de interogare diagnostica, o capacitate pe care inginerii nostri o folosesc pentru a reproduce si depana performanta interogarii.
În timp ce aplicaţi replay-ul de interogare diagnostică la o interogare mare, complexă, un bug software a cauzat replay-uri de interogare să se răspândească în întreaga flotă în loc de a rămâne limitată la un singur server. În plus, a cauzat mult mai multe date decât ar fi trebuit salvate fără evacuarea la timp pe un singur server. Doi factori au lărgit apoi impactul problemei:
* Un singur volum complet de stocare a luat un server complet din serviciu. Fiecare server își tratează cache-ul ca nesănătos dacă unul dintre volumele sale de stocare depășește un prag de utilizare, chiar și atunci când toate celelalte volume sunt sănătoase. Datele de reluare au fost scrise la un volum specific pe fiecare server, astfel încât serverele din regiune nu și-au verificat sănătatea aproape simultan.
* Limitele de curățare nu au reprezentat mărimea datelor. Siguranța care limitează reluarea datelor pe disk a numărat elemente la nivelul de aplicare mai degrabă decât octeți la nivelul sistemului de fișiere, astfel încât un număr mic de capturi neașteptat de mari au trecut verificarea în timp ce consumul de cea mai mare parte a capacității de volum.
Împreună, acestea au permis un singur flux de lucru de depanare care, în mod normal, are o amprentă neglijabilă pentru a întrerupe interogarea producției care servește în întreaga regiune a SUA.
Cronologie \ (Ora Pacificului, 26 august 2026\)
* ** 2:00 PM**
* **2:17 PM**
* **2:39 PM**
* **2:53 PM**
* **3:19 PM**
* **3:45 PM** Reluarea diagnosticului care a declanșat problema a fost complet dezactivată în aceeași seară.
Cauza rădăcină
1. ** Un bug software în reluarea interogării noastre a cauzat scrieri nelegate la stocarea producției.** O capacitate recent utilizată pentru reproducerea interogărilor a manipulat greșit o anumită clasă de interogări complexe, ceea ce a dus la răspândirea capturilor către fiecare server de interogare din regiune și a scris mult mai multe date către volumele afectate decât proiectul presupus.
2. ** Redarea fișierelor consumate capacitatea discului care interogare de servire depinde de.** Replay-ul a scris fișierele sale pe discurile locale ale serverelor de interogare, astfel încât reluarea datelor fugite a epuizat capacitatea de stocare a serverelor necesare pentru a răspunde la întrebări.
3. ** Safeguards doar parțial a reprezentat pentru comportamentul.** Politica de curăţare a datelor de diagnosticare a limitat numărul de articole de pe disc, dar nu mărimea lor totală, aşa că nu s-a angajat. Alerta asupra volumului de stocare a marcat creșterea, dar nu a fost escaladată ca fiind critică pe bază de per-server, care a întârziat detectarea până când au început eșecurile de interogare.
Ce schimbăm
Starea finală pe care o construim către: interogarea interogării interne a diagnosticului redă datele stocate în stocarea obiectelor dedicate, punând nici o sarcină pe serverele de interogare a producției.
Deja implementat:
* **Disabled the intern tooling** that cause the incident, and remediated the countain issue so diagnostic captures are limited to a single server and the specific interogare class is manipulated just.
* ** Întocmit procedura de recuperare ţintită** folosită în timpul incidentului, adică de compensare numai volumul de stocare afectate, mai degrabă decât repornirea grupuri de servere complete, în runbook-urile noastre operaţionale, scurtarea timpului de recuperare în cazul în care orice volum de capacitate se termină în viitor.
În curs:
* **Filesystem-nivel, dimensiuni-based limite on diagnostic replay data**, plafonarea octeților totale pe disc mai degrabă decât numărul de elemente, astfel încât capturi supradimensionate sunt respinse sau evacuate înainte ca acestea să poată afecta capacitatea de volum.
* **Stricter de stocare alertare**, escaladarea saturarea volumului per-server ca critică înainte de a putea afecta interogarea controale de sănătate.
* **Moving interogare replay data to dedicate object storage,** so it consums no resources on production interogare servers.
Întrebări comune
* ** A fost orice date pierdute? ** Nu. Ingestia de date nu a fost afectată pe tot parcursul incidentului: evenimentele au continuat să fie colectate, la coadă şi depozitate în mod normal. Doar capacitatea de a interoga a fost întreruptă. Odată ce serviciul a fost restabilit, toate rapoartele au reflectat date complete.
* ** Au fost salvate rapoarte, borduri, sau setările de proiect afectate?** Nu. Incidentul a afectat doar executarea interogării. Nimic stocat în proiectul tău nu s-a schimbat.
* ** De ce a afectat mai multe proiecte americane deodată?** Datele de diagnosticare supradimensionate replay scrise pe discurile fiecărui server de interogare în aproape același timp, și fiecare server se elimină din serviciu atunci când se umple un volum. Prevenirea instrumentelor interne de a consuma de stocare interogare-server este o parte centrală a activității noastre de remediere.
Cum este prevenit acest lucru merge mai departe? Problema instrumentelor este rezolvată, iar instrumentele rămân dezactivate până când există limite bazate pe dimensiuni. Alerta de păstrare este în curs de înăsprire, astfel saturarea este prins înainte de a afecta serviciul de interogare. Structural, mutăm date de diagnosticare de pe serverele de interogare de producție în întregime, astfel încât datele de depanare interne nu vor consuma nicio stocare pe serverele responsabile pentru procesarea interogărilor.
Ne cerem scuze pentru întrerupere și pentru rapoartele de timp nu au fost disponibile. Vă rugăm să contactați prin intermediul echipei de cont sau suport cu orice întrebări.
Traducere automată din actualizarea oficială a incidentului.
Aspecte Popularea Proprietăților Evenimentului în meniurile dropdown
În prezent avem probleme cu proprietățile de eveniment populând în meniurile de scădere. Apreciem răbdarea dumneavoastră în timp ce inginerii noștri lucrează pentru a restabili funcționalitatea. Dacă aveți întrebări, vă rugăm să contactați [email protected]
identified
Continuăm să lucrăm la o soluție pentru această problemă.
monitoring
A fost implementată o soluţie şi monitorizăm rezultatele.
resolved
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
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.
identified
The issue has been identified and fix is being implemented.
monitoring
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.
resolved
This incident has been resolved.
Traducere automată din actualizarea oficială a incidentului.
Probleme de servire a răspunsurilor de către agentul Mixpanel
A început 22 iulie 2026 la 08:03 UTC · 6h 44m
Pending
investigating
În prezent avem probleme cu agentul Mixpanel în cadrul aplicaţiei web. Echipa noastră de ingineri a fost alertată şi investighează problema şi lucrează la restabilirea funcţionalităţii sale. Vă apreciem răbdarea în timp ce lucrăm pentru a rezolva această problemă.
Dacă aveți întrebări, vă rugăm să contactați sprijinul.
investigating
echipa continuă să investigheze problema și pașii următori. Mulţumesc pentru răbdare.
monitoring
A fost implementată o soluţie şi monitorizăm rezultatele.
resolved
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
Întârziere temporară a datelor pentru proiectele din SUA
A început 11 iulie 2026 la 07:53 UTC · 8h 1m
IssuesIncident minor
Componente afectate
Ingestion API Availability (US)
investigating
În prezent, ne confruntăm cu întârzieri în conducta noastră de ingerare a datelor, care afectează datele în timp real pentru proiectele înscrise în proiectele din SUA, ceea ce duce la întârzieri pentru un subset de proiecte. Deși nu se pierd date, echipa noastră de inginerie investighează în mod activ problema și lucrează pentru a restabili funcționalitatea în timp real cât mai repede posibil. Îţi apreciem răbdarea în acest timp.
Dacă aveți întrebări, vă rugăm să contactați sprijinul.
investigating
Continuăm să investigăm această problemă.
identified
Problema a fost identificată și se pune în aplicare o soluție.
identified
Continuăm să lucrăm la o soluție pentru această problemă.
monitoring
A fost implementată o soluţie şi monitorizăm rezultatele.
resolved
Acest incident a fost rezolvat.
postmortem
Sumarul
Între aproximativ ** 11:35 PM PT pe 10 iulie și 7:19 AM PT pe 11 iulie 2026**, ingestie de date pentru proiectele Mixpanel din regiunea SUA a fugit în urmă cu până la ~2 ore. În timpul acestei ferestre, rapoartele și tablourile de bord au arătat temporar date incomplete **Nu s-au pierdut date.** Toate evenimentele au fost coadă la coadă în mod durabil și prelucrate în întregime odată ce backlog șterse; indicatorii au revenit la valori exacte pe cont propriu, fără nicio acțiune a clientului necesară.
Cauza provine din controalele noastre de ingestie: pentru un număr mic de proiecte de foarte mare volum, ratele de ingestie pe care le-am permis au deviat de la alinierea la capacitatea prevăzută pentru aceste proiecte. Importuri istorice mari Fixările de mai jos realiniază aceste controale astfel încât orice import, de orice dimensiune, să fie păstrat automat în limite sigure.
Ce s-a întâmplat
Conducta de ingestie a Mixpanelului este fragmentată și multi-tenant: datele fiecărui proiect sunt distribuite într-un set de partiții marit pentru volumul preconizat, iar pentru supraînregistrare, evenimentele de la mulți clienți sunt prelucrate împreună în loturi. Acest proiect oferă o eficienţă ridicată, dar depinde de un singur invariant: rata la care admitem că traficul unui proiect trebuie să corespundă capacităţii prevăzute pentru acesta. În cazul în care invariantul deține, chiar și importurile foarte mari sunt absorbite fără probleme.
Aici, nu a rezistat. Un număr mic de importuri de date istorice foarte mari au evoluat pe proiecte ale căror rate permise de ingerare au crescut, în timp, mult peste capacitatea de partiție furnizată. Volumul în exces s-a concentrat pe partiții specifice ca ** pete fierbinți**, saturând partea flotei de streaming care le servește. Doi factori au lărgit apoi impactul:
*** Procesarea în mai multe benzi a amplificat punctele fierbinţi.** Deoarece evenimentele de la mulți clienți călătoresc împreună în loturi, lente și eșecuri pe partițiile supraîncărcate întârziat evenimente clienților independenți care împart aceste loturi.
* ** Scal-up-ul automatic a fost ineficient. ** Capacitatea de adăugare nu poate dizolva un punct fierbinte de acest tip, deoarece partițiile supraîncărcate rămân fixate la aceeași infrastructură și o limită de capacitate într-o componentă a infrastructurii noastre de streaming a împiedicat intrarea în vigoare a capacității adăugate.
Împreună, acestea au transformat ceea ce ar fi trebuit să fie o încetinire scurtă, autovindecătoare, într-o întârziere de mai multe ore care necesita intervenţie manuală.
Cronologie, 10 iulie 11
* **11:35 PM**
* **12:49 AM**
* **1:23 AM ** Importul cel mai mare a fost oprit.
* **1:55
* **7:19 AM** Pagina de stare a trecut la monitorizare, apoi rezolvată după o perioadă de observare stabilă.
Cauza rădăcină
1. ** Limitele ratei de ingestiare sunt corelate greşit cu capacitatea furnizată.** Pentru proiectele de conducere, ratele pe care platforma noastră le-a admis au crescut de pe urma infrastructurii prevăzute pentru acestea, astfel încât importurile legitime de mare volum au fost lăsate să intre mai repede decât ar fi putut absorbi partițiile lor. Aceasta este cauza rădăcină sistemică. Importurile în sine au reprezentat o utilizare legitimă a platformei.
2. ** Procesarea bazată pe mai multe tehnologii a amplificat supraîncărcarea. ** Eșecurile asupra partițiilor supraîncărcate au întârziat evenimentele clienților neafiliați care împart aceleași loturi de procesare, răspândind o problemă localizată pe platformă.
3. ** Traficul către partițiile supraîncărcate nu a putut fi redistribuit.** Partition-to-server asignation in the streaming strat was not load-aware, so the hot spots ramased tounded to the same servers, indiferent de dimensiunea flotei O limită de scalare într-o componentă a infrastructurii noastre de streaming compus acest lucru prin prevenirea scară-up de la adăugarea de capacitate, care a întârziat diagnosticul până inginerii au intervenit manual.
Ce schimbăm
Starea finală pe care o construim către: ** limitele de ingestie ale fiecărui proiect se potrivesc automat cu capacitatea sa furnizată, astfel încât importurile de orice dimensiune, inclusiv backfill-uri istorice complete și sincronizări de depozit de date, pot rula fără coordonare prealabilă, iar volumul unui proiect este împiedicat să afecteze prospețimea datelor altuia**.
Deja desfăşurate
* ** Improved hot-spot handling.** Distribuţia traficului în stratul de streaming este acum conştientă de sarcină, răspândind încărcătura concentrată mai uniform în întreaga flotă, iar obiectele cu probleme individuale sunt rejudecate separat în loc să-şi reţină restul lotului, reducând, deşi nu eliminăm, impactul pe care o supraîncărcare localizată îl poate avea asupra traficului fără legătură.
* ** Re-a furnizat volumul cel mai mare de muncă** pe infrastructura de dimensiuni adecvate, prioritizate de risc.
S-au desfăşurat deja
* ** Auditat și re-a reglat profilul de capacitate al flotei** astfel încât serverele individuale au substanțial mai mult loc pentru sarcina concentrată, și a lucrat cu furnizorul pentru a rezolva limita de scalare întâlnite în timpul incidentului.
În curs:
* ** Limitarea ratei de conştientizare a capacităţii**
* **Monitorizarea volumului cu granulație fină și alertarea** astfel încât alinierea capacității este detectată și corectată înainte de a putea afecta orice client.
* Evaluarea izolarea mai puternică a volumului de muncă / recuperarea backlog prioritizarea pentru căile de trafic vrac / backfill, astfel încât importurile istorice au redus impactul asupra traficului live
Întrebări comune
* ** A fost orice date pierdute? ** Nu Evenimentele au fost în mod durabil coadă pe tot parcursul incidentului și au fost prelucrate pe deplin odată ce backlog eliminate. Orice picaturi metrice observate în timpul ferestrei au fost un artefact de afișare a întârzierii și auto-corectare.
* ** Nu am nevoie pentru a coordona importurile mari sau backfills cu Mixpanel?** Nu. Scopul nostru este ca platforma să păstreze automat orice import în cadrul tarifelor de siguranță, astfel încât backfills și sincronizări depozit poate rula fără programare sau notificare. Încă continuăm controalele de capacitate conştientă care asigură acest lucru. Între timp, dacă sunteți de planificare un import neobișnuit de mare sau backfill, vă recomandăm coordonarea cu echipa de cont astfel încât să putem confirma capacitatea în avans.
Cum este prevenit acest lucru merge mai departe? Fixare sistemică este înăsprirea lacunelor între limitele individuale ale ratei de proiect acordate și capacitatea reală prevăzută a fiecărui proiect, precum și extinderea ratei de limitare la căile de ingerare care anterior nu au fost luate în considerare. În plus, limitarea de scalare care a prelungit incidentul este stabilită, conducta retries acum elemente individuale probleme separat, astfel încât o suprasarcină localizată are mult mai puțin impact asupra traficului fără legătură, și trafic în vrac este în continuare izolat de traficul live.
* ** Poate proiectele individuale să fie prioritizate în timpul recuperării?** Această capacitate nu a existat în timpul incidentului. Suntem evaluarea mecanismelor de prioritizare pentru recuperarea backlog ca parte a activității noastre de monitorizare.
Ne cerem scuze pentru întrerupere şi pentru îngrijorarea pe care au cauzat-o indicatorii deprimaţi temporar. Vă rugăm să contactați prin intermediul echipei de cont sau suport cu orice întrebări.
Traducere automată din actualizarea oficială a incidentului.
Mixpanel se confruntă cu performanțe degradate cu API nostru Query, inclusiv creșterea latenței. Puteţi vedea rapoarte de încărcare lentă sau erori de interogare. Apreciem răbdarea dumneavoastră în timp ce inginerii noștri lucrează pentru a restabili funcționalitatea normală. Vom posta actualizări de progres pe pagina noastră de stare.
Dacă aveți întrebări, vă rugăm să contactați sprijinul.
identified
Problema a fost identificată și se pune în aplicare o soluție.
identified
Latenţa de interogare s-a stabilizat, deşi echipa noastră continuă să investigheze cauza principală a performanţei degradate. Vom continua să postăm actualizări pe măsură ce investigaţia noastră progresează. Mulţumesc pentru răbdare.
monitoring
A fost implementată o soluţie şi monitorizăm rezultatele.
resolved
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
Issue with Inviting and Deleting Users
A început 3 iunie 2026 la 20:05 UTC · 1h 22m
Pending
investigating
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]
identified
The issue has been identified and a fix is being implemented.
resolved
This incident has been resolved.
Temporary Data Ingestion Delay for US, India and EU projects
A început 2 iunie 2026 la 11:02 UTC · 5h 51m
Pending
investigating
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
identified
The issue has been identified and a fix is being implemented.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
Temporary Data Ingestion Delay for US, India and EU projects
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
investigating
We have now identified an ingestion delay for EU projects, and are continuing to investigate the issue. Thank you for your patience.
identified
The issue has been identified, and a fix is being implemented.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
Board Access Issues
A început 19 mai 2026 la 19:03 UTC · 2h 15m
Pending
investigating
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.
identified
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.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
Query API degraded performance
A început 14 mai 2026 la 23:17 UTC · 1d 3h
IssuesIncident minor
Componente afectate
Application Availability (US)
investigating
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.
identified
The issue has been identified and a fix is being implemented.
identified
We are continuing to work on a fix for this issue.
identified
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.
identified
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.
identified
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.
identified
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.
identified
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.
identified
Query latency has returned to normal levels. We are continuing to monitor.
identified
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.
identified
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.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
postmortem
# 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.
Data Volume Monitoring degraded performance
A început 13 mai 2026 la 16:34 UTC · 21h 1m
Pending
identified
Data Volume Monitoring is again experiencing degraded performance due to a recurring upstream provider disruption. We're mitigating now.
identified
We are continuing to work on a fix for this issue.
resolved
This incident has been resolved.
Data Volume Monitoring degraded performance
A început 12 mai 2026 la 17:17 UTC · 3h 57m
Pending
Componente afectate
Application Availability (US)
investigating
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).
identified
An upstream service provider outage is causing this issue. We are deploying a fix to mitigate the disruption.
monitoring
A fix has been implemented, and we are monitoring the result.
resolved
This incident has been resolved.
Snowflake pipeline exports degraded
A început 6 mai 2026 la 00:00 UTC · 20h 4m
Pending
investigating
A subset of projects are experiencing issues exporting data to the Snowflake warehouse via Mixpanel pipelines. We are currently investigating this issue.
identified
We have identified the issue affecting Snowflake pipeline exports for a subset of projects, and our engineering team is working on a resolution.
resolved
This incident has been resolved.
Credit Card Processing Interruption
A început 9 aprilie 2026 la 20:03 UTC · 1h 41m
Pending
identified
We are currently experiencing an interruption with our credit card processing. Our engineers have identified the issue and are working on a fix.
monitoring
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.
resolved
This incident has been resolved.
Degraded Query API Performance impacting EU Projects
A început 16 martie 2026 la 16:50 UTC · 4h 56m
IssuesIncident minor
Componente afectate
Application Availability (EU)
identified
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.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
Error loading Mixpanel Webapp
A început 2 martie 2026 la 21:00 UTC · 53m
Pending
investigating
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.
identified
The issue has been identified and a fix is being implemented.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved. If Mixpanel is still not loading, please clear your cache and cookies.
