Cronologia delle interruzioni di Mixpanel

1. 21 ottobre 2026 alle ore 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 ottobre 2026 alle ore 20:15 UTCresolved

   This incident has been resolved.

1. 21 ottobre 2026 alle ore 22:28 UTCmonitoring

   Abbiamo ricevuto rapporti che le richieste di decidere.mixpanel.com stanno fallendo. Qualsiasi traffico inviato attraverso deci.mixpanel.com può essere influenzato, comprese le bandiere di funzionalità e il monitoraggio degli eventi. Per ripristinare il servizio, puntare le richieste api.mixpanel.com (US), api-eu.mixpanel.com (EU), o api-in.mixpanel.com (IN), a seconda della residenza dati del tuo progetto. Abbiamo implementato una mitigazione e stiamo monitorando i risultati. Stiamo vedendo il traffico ripristinato. pubblicheremo aggiornamenti sui progressi nella nostra pagina di stato. Se avete domande, si prega di contattare il supporto.

2. 22 ottobre 2026 alle ore 01:34 UTCresolved

   Questo incidente è stato risolto.

3. 24 ottobre 2026 alle ore 01:58 UTCpostmortem

   # **Mixpanel RCA: Richieste a** [**decide.mixpanel.com**](http://decide.mixpanel.com) **Failed, 15–21, 2026** Traduzione: Dal 15 ottobre 2026 al 21 ottobre 2026, richieste inviate a `decide.mixpanel.com` e `api-decide.mixpanel.com` fallite. Questo ha interessato i clienti che hanno inviato il monitoraggio degli eventi, gli aggiornamenti del profilo, o le richieste della bandiera di funzionalità a questo hostname, di solito attraverso un proxy. Gli eventi inviati a questo dominio durante questa finestra non sono stati ricevuti da Mixpanel e questi dati non possono essere ripristinati da Mixpanel. **Traffico inviato a** `api.mixpanel.com`****,** `api-js.mixpanel.com, ``api-eu.mixpanel.com`**, e** `api-in.mixpanel.com` **non siamo interessati.** Il servizio su questo hostname è stato involontariamente influenzato mentre stavamo rimuovendo l'infrastruttura endpoint `/decide`. I nomi host sono stati trattati come parte del endpoint a causa di una comprensione errata delle dipendenze del sistema. Per prevenire questa classe di emissione, stiamo aggiungendo il monitoraggio del traffico per i nomi host `decide.mixpanel.com` e `api-decide.mixpanel.com`. Richiederemo anche traffico zero confermato a livello di hostname prima che venga rimosso qualsiasi hostname. **Abbiamo da allora restaurato servizio su** `decide.mixpanel.com` . # Che e' successo # Older Mixpanel SDKs chiamato `/decide` endpoint per ottenere la configurazione per [**Legacy Automatically Tracked Mobile Events**](https://docs.mixpanel.com/docs/tracking-methods/sdks/ios#legacy-automatically-tracked-events). Abbiamo [annunciato il ritiro del punto finale](https://docs.mixpanel.com/changelogs#2026-01-26), e per qualche tempo `/decide` ha restituito una risposta `410`. Separatamente, `decide.mixpanel.com` e `api-decide.mixpanel.com` agito come alias per i nostri standard API hostnames. Ad esempio, `decide.mixpanel.com/track` eventi ingeriti lo stesso modo `api-js.mixpanel.com/track` fa. Alcuni clienti avevano impostato proxies o configurazioni SDK per inviare il loro traffico a questi hostname. Il 15 ottobre alle 19:40 PM CDT, durante la pulizia finale del `/decide` endpoint, abbiamo rimosso i record DNS per `decide.mixpanel.com` e `api-decide.mixpanel.com` e rimosso entrambi i nomi host dal nostro bilanciatore di carico. Prima di fare il cambiamento, abbiamo confermato che il traffico al punto finale `/decide` era sceso a zero. Tuttavia, il nostro monitoraggio misurato traffico per endpoint piuttosto che per hostname. Pertanto, non mostrava che altre richieste, come `/track` e `/flags`, stavano ancora raggiungendo Mixpanel attraverso questi nomi host. Da allora, tutte le richieste a questo nome host sono fallite, inclusi gli endpoint come `/track`, `/engage`, `/groups` e `/flags`. * **Eventi e profili:** Eventi, profilati e qualsiasi dato destinato a [Ingestion API endpoints](https://docs.mixpanel.com/reference/ingestion-api) a questi hostnames durante questa finestra mai raggiunto Mixpanel, quindi non abbiamo una copia da ripristinare. Se hai mantenuto questi dati altrove, ad esempio nei registri proxy o nel tuo data warehouse, puoi ri-spedirlo a Ingestion API [/import](https://docs.mixpanel.com/reference/import-events), [/engage,](https://docs.mixpanel.com/reference/profile-set) e [/groups]( # Bandiere delle caratteristiche # Le richieste della bandiera della caratteristica inviate a questi nomi host non sono riusciti. SDKs ha servito l'ultima variante memorizzata se uno esisteva, o altrimenti il valore di fallback configurato nel vostro codice. ## Timeline \(Ora centrale, ottobre 2026\) Traduzione: La rimozione del nome host viene applicata. Le richieste di `decide.mixpanel.com` e `api-decide.mixpanel.com` iniziano a fallire. Traduzione: Riceviamo il primo rapporto cliente. È inizialmente inteso per essere collegato al piano `/decide ` pensione. Traduzione: A seguito di un aumento dei rapporti dei clienti circa il mancato monitoraggio per i proxy, identifichiamo la rimozione hostname come causa. Traduzione: Ristabiliamo i nomi degli ospiti. `/decide` rimane in pensione. Traduzione: Confermiamo il traffico ai nomi host restaurati è stato recuperato. Traduzione: L'incidente e' risolto. # 1. Durante il `/decide` pensionamento, `decide.mixpanel.com` e `api-decide.mixpanel.com` sono stati rimossi involontariamente. 2. Questi hostname erano stati configurati per accettare tutto il traffico API, non solo le richieste `/decide`, e questo comportamento non era documentato. 3. Il nostro monitoraggio ha tracciato il traffico al `/decide` endpoint ma non a questi hostname, così i controlli pre-cambiamento non hanno dimostrato che altro traffico era ancora attivo. 4. Poiché i nomi host e il punto finale in pensione condividono un nome, i rapporti dei clienti iniziali sono stati inizialmente interpretati come effetti attesi del `/decide` pensionamento annunciato. Questa escalation ritardata. ##### **Quello che stiamo cambiando** ♪Monitoring and alerts ♪ Stiamo aggiungendo il monitoraggio del traffico e dei tassi di errore e avvisi per `decide.mixpanel.com` e `api-decide.mixpanel.com`, così i guasti vengono rilevati automaticamente piuttosto che attraverso i rapporti del cliente. Revisione: Stiamo controllando tutti gli hostname API pubblici e gli alias di routing per punti di ingresso non documentati simili, e rivedere nuovi hostname e alias prima di andare in diretta. Stiamo anche tracciando il traffico che arriva su qualsiasi nome host inaspettato. Traduzione: Prima di qualsiasi cambiamento futuro a un hostname pubblico, confermeremo zero traffico a livello di hostname, e identificheremo e contatteremo tutti i progetti che lo utilizzano ancora. Traduzione: Daremo ai clienti l'avviso anticipato dei cambiamenti delle infrastrutture materiali che influiscono sui nomi host pubblici, inclusa la pubblicazione su una linea temporale nel nostro changelog. ♪Already schierato ♪ * Restaurato `decide.mixpanel.com` e `api-decide.mixpanel.com` * `/decide` rimane in pensione #######****Le domande comuni * I miei dati sono influenzati? Solo se il vostro SDK o proxy ha inviato richieste a `decide.mixpanel.com` o `api-decide.mixpanel.com` tra il 15 ottobre e il 21 ottobre. I dati inviati durante quella finestra non sono stati ricevuti e non possono essere ripristinati da Mixpanel. Se hai mantenuto una copia di tali dati, puoi ri-spedirlo a Mixpanel utilizzando i nostri endpoint API Ingestion come `/import` per gli eventi. Devo cambiare qualcosa? No, i domini funzionano di nuovo. Si consiglia di utilizzare `api.mixpanel.com` \(o `api-eu.mixpanel.com` / `api-in.mixpanel.com` per la residenza dei dati UE e India\) come dominio API. # Sta tornando? # No. Resta in pensione come annunciato, ed è separato dal nome host `decide.mixpanel.com`. Ci dispiace per la rottura. Se hai domande sul tuo progetto, contatta il team del tuo account o il supporto Mixpanel.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 8 ottobre 2026 alle ore 16:32 UTCinvestigating

   Attualmente stiamo riscontrando ritardi nella nostra pipeline di ingestione dei dati, che sta influenzando i dati in tempo reale per i progetti iscritti nei progetti statunitensi, con conseguente ritardo per un sottoinsieme di progetti. Mentre nessun dato viene perso, il nostro team di ingegneri sta attivamente indagando sulla questione e lavorando per ripristinare la funzionalità in tempo reale il più rapidamente possibile. Apprezziamo la vostra pazienza in questo momento. Se avete domande, si prega di contattare il supporto.

2. 8 ottobre 2026 alle ore 17:32 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 8 ottobre 2026 alle ore 18:31 UTCidentified

   Abbiamo identificato la causa del ritardo dell'ingestione come un problema a monte con il nostro provider di cloud storage, Google Cloud, che colpisce un sottoinsieme di progetti statunitensi. Google ha confermato questo come un problema di alta priorità sulla loro fine, ma non ha ancora fornito un ETA. Abbiamo implementato mitigazioni per garantire un recupero regolare una volta che si cancella. Non ci sono eventi persi. Questo è rigorosamente un ritardo di ingestione, tutti i dati interessati continueranno a essere ritrattati una volta risolto il problema.

4. 8 ottobre 2026 alle ore 19:30 UTCmonitoring

   Le nostre metriche mostrano ingestione è catturato e non più vivendo ritardo. Google non ha ancora confermato la risoluzione del problema a monte sottostante alla loro fine, quindi stiamo continuando a monitorare da vicino in caso di ricorrenza.

5. 8 ottobre 2026 alle ore 21:30 UTCmonitoring

   Nessun cambiamento dal nostro ultimo aggiornamento, continuiamo a osservare nessun ritardo attivo di ingestione sulla nostra fine, e tutti i sistemi rimangono sani. Stiamo continuando a monitorare da vicino.

6. 8 ottobre 2026 alle ore 22:30 UTCmonitoring

   Stiamo continuando a monitorare eventuali ulteriori problemi.

7. 8 ottobre 2026 alle ore 23:30 UTCmonitoring

   I sistemi sono rimasti stabili senza ricorrenza del ritardo di ingestione. Stiamo tenendo d'occhio le cose mentre aspettiamo la conferma finale dal nostro fornitore a monte.

8. 9 ottobre 2026 alle ore 00:22 UTCresolved

   Questo incidente è stato risolto. Il problema a monte con il nostro provider di cloud storage è stato risolto e la nostra pipeline di ingestione funziona normalmente senza ritardi attivi. Nessun evento è stato perso durante questo incidente, tutti i dati interessati sono stati completamente ritrattati. Grazie per la vostra pazienza durante questo incidente.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 26 agosto 2026 alle ore 21:39 UTCinvestigating

   Mixpanel sta sperimentando le prestazioni di Query API degradate, con conseguente HTTP 500 risposte quando query report per i progetti con US Data Residency. I progetti con UE e IN Data Residency rimangono inalterati. Apprezziamo la vostra pazienza mentre i nostri ingegneri lavorano per ripristinare la normale funzionalità. pubblicheremo aggiornamenti sui progressi nella nostra pagina di stato. Se avete domande, si prega di contattare il supporto.

2. 26 agosto 2026 alle ore 22:11 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 26 agosto 2026 alle ore 22:28 UTCmonitoring

   Una correzione è stata implementata, e stiamo vedendo migliori tassi di successo per l'API di Query. Continueremo a monitorare per garantire la stabilità.

4. 26 agosto 2026 alle ore 22:45 UTCresolved

   Questo incidente è stato risolto.

5. 8 settembre 2026 alle ore 18:25 UTCpostmortem

   # Mixpanel RCA: Disturbo temporaneo del servizio di query per i progetti americani 26 agosto 2026 # Sommario Tra circa **2:02 PM e 3:19 PM PT il 26 agosto 2026**, i progetti nella regione degli Stati Uniti hanno sperimentato i rapporti di caricamento dei guasti e l'esecuzione delle domande attraverso l'UI di Mixpanel e l'API di Query. Durante questa finestra, alcune domande nella regione hanno fallito o restituito errori. **Nessun dato del cliente è stato perso, e l'ingestione dei dati non è stata influenzata.** Tutti gli eventi hanno continuato a essere raccolti e memorizzati normalmente durante l'incidente; una volta che il servizio di query è stato ripristinato, tutti i rapporti hanno riflettuto dati completi e precisi senza l'azione del cliente richiesto. La causa è stata identificata come uno strumento interno recentemente implementato per la riproduzione di query diagnostica, una capacità che i nostri ingegneri utilizzano per eseguire copie di query passate per debug le prestazioni, che inaspettatamente ha scritto grandi quantità di dati ai dischi dei nostri server di query, consumando capacità di archiviazione che i server devono operare. Quando quei dischi riempiti, i server interessati si sono allontanati dal servizio. Il servizio è stato ripristinato, i server impattati sono stati riportati on-line, e la strumentazione interna è stata disabilitata. Le correzioni sottostanti aggiungono salvaguardie di archiviazione per rimuovere la capacità degli strumenti interni di consumare risorse su server di query, e sono progettati per impedire che questa classe di fallimento accada di nuovo in futuro. # Che e' successo # Il motore di query di Mixpanel viene eseguito su una flotta di server che ogni utilizzano un insieme di volumi di archiviazione locali per memorizzare i dati necessari per rispondere rapidamente alle domande. Separatamente, i nostri ingegneri utilizzano strumenti di rigioco di query diagnostici, una capacità che i nostri ingegneri utilizzano per riprodurre e debug le prestazioni di query. Durante l'applicazione della query diagnostica replay tooling a una grande e complessa query, un bug del software ha causato la riplay di query cattura per fan fuori attraverso l'intera flotta invece di rimanere confinato a un singolo server. Inoltre, ha causato molto più dati che destinati a essere salvati senza evizione tempestiva su un singolo server. Due fattori hanno poi ampliato l'impatto del problema: * Un unico volume di archiviazione completo ha preso un server completamente fuori servizio. Ogni server tratta la sua cache come malsano se uno dei suoi volumi di archiviazione attraversa una soglia di utilizzo, anche quando tutti gli altri volumi sono sani. I dati di riproduzione sono stati scritti a un volume specifico su ogni server, quindi i server di tutta la regione hanno fallito i loro controlli sanitari quasi simultaneamente. * I limiti di pulizia non hanno tenuto conto delle dimensioni dei dati. La protezione che limita i dati di riproduzione sul disco contati elementi a livello di applicazione piuttosto che byte a livello del filesystem, quindi un piccolo numero di catture inaspettatamente grandi ha superato il controllo mentre consuma la maggior parte della capacità del volume. Insieme, questi hanno permesso un unico flusso di lavoro di debug che normalmente ha un'impronta trascurabile per interrompere la domanda di produzione che serve in tutta la regione degli Stati Uniti. # Timeline \(Pacific Time, 26 agosto, 2026\) * **2:00 PM** — Prima cattura di rigioco diagnostico di grandi dimensioni è stato scritto; i volumi di archiviazione hanno cominciato a raggiungere la loro capacità e la velocità di successo di query ha cominciato a cadere poco dopo. * **2:17 PM** — Avviso automatico ha chiamato l'ingegnere on-call; le indagini hanno cominciato immediatamente e gli ingegneri aggiuntivi sono stati impegnati. * **2:39 PM** — Errore della pagina di stato pubblicato; banner in-app visualizzato alle 2:40 PM. * **2:53 PM** — Causa radice identificata; gli sforzi di recupero hanno cominciato sul primo gruppo di server interessato. * **3:19 PM** — Servizio di query ripristinato per la maggior parte del traffico; il gruppo di server finale completamente recuperato alle 3:27 PM. * **3:45 PM** — Incidente risolto dopo un periodo di osservazione stabile. Lo strumento di riproduzione diagnostica che ha innescato il problema è stato completamente disabilitato la stessa sera. # Root cause # 1. ** Un bug software nella nostra ricerca di riplay tooling ha causato scritture non-bounded alla conservazione di produzione**. Una capacità distribuita di recente per la riproduzione delle query ha trascurato una particolare classe di query complessa, causando la diffusione delle catture ad ogni server di query nella regione e la scrittura di molto più dati ai volumi interessati rispetto al progetto assunto. 2. **Replay file consumati capacità disco che query serve dipende da.** Lo strumento di replay ha scritto i suoi file sui dischi locali dei server query, quindi i dati di runaway riproducono la capacità di archiviazione esausta dei server devono rispondere alle domande. 3. **Le guardie di sicurezza hanno solo parzialmente rappresentato il comportamento.** La politica di pulizia per i dati di rigioco diagnostico ha limitato il numero di elementi sul disco, ma non la loro dimensione totale, quindi non ha coinvolto. Alerting su volumi di archiviazione ha contrassegnato la crescita, ma non è stato aumentato come critico su una base per-server, che ha ritardato il rilevamento fino a quando i guasti di query hanno cominciato. # Quello che stiamo cambiando # Lo stato finale che stiamo costruendo verso: la query diagnostica interna rielabora i dati memorizzati nella memorizzazione di oggetti dedicati, non ponendo alcun carico sui server di query di produzione. Già schierato: * **Disabled the internal tooling** che ha causato l'incidente, e ha risolto il problema sottostante in modo che le catture diagnostiche siano limitate a un singolo server e la classe di query specifica viene gestita correttamente. * **Documentato la procedura di recupero mirata** utilizzata durante l'incidente, cioè, cancellando solo il volume di archiviazione interessato piuttosto che riavviare i gruppi di server completi, nei nostri runbook operativi, accorciando il tempo di recupero se la capacità di qualsiasi volume si esaurisce in futuro. In corso: * **Filesystem-level, limiti basati sulle dimensioni sui dati di riproduzione diagnostica**, tappare byte totali su disco piuttosto che conta oggetti, così le catture oversize vengono rifiutate o sfrattate prima di poter influenzare la capacità del volume. * ** Avviso di archiviazione di Straicter**, aumentando la saturazione del volume per server come critico prima che possa influenzare i controlli sanitari di query. * **Moving query replay dati per lo storage dedicato agli oggetti,** in modo da non consumare risorse sui server di query di produzione. # Domande comuni # # Ci sono dati persi? # No. L'ingestione dei dati non è stata influenzata durante l'incidente: gli eventi sono continuati a essere raccolti, in coda e memorizzati normalmente. Solo la capacità di query è stata interrotta. Una volta che il servizio è stato ripristinato, tutti i rapporti hanno riflesso i dati completi. * * * Sono stati salvati report, dashboard o impostazioni di progetto interessate?** No. L'incidente ha interessato solo l'esecuzione delle query. Non è cambiato nulla nel tuo progetto. * ** Perché ha colpito più progetti statunitensi in una sola volta?** I dati di replay diagnostici di grandi dimensioni scritti su ogni disco del server di query quasi allo stesso tempo, e ogni server si rimuove dal servizio quando qualsiasi volume si riempie. Prevenire lo strumento interno dal consumo di storage query-server è una parte fondamentale del nostro lavoro di bonifica. # Come puo' andare avanti? # Il problema degli utensili viene risolto e l'attrezzo rimane disabilitato fino a quando i limiti basati sulle dimensioni sono in vigore. L'avviso di stoccaggio è serrato in modo che la saturazione venga catturata prima che influisca sul servizio di query. Strutturalmente, stiamo spostando i dati diagnostici fuori server di query di produzione interamente, così i dati di debugging interni non consumano archiviazione sui server responsabili dell'elaborazione delle query. Ci scusiamo per l'interruzione e per i rapporti di tempo non erano disponibili. Si prega di raggiungere attraverso il vostro team di account o il supporto con qualsiasi domanda.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 19 agosto 2026 alle ore 23:20 UTCidentified

   Attualmente stiamo vivendo problemi con populating proprietà eventi nei menu a tendina. Apprezziamo la vostra pazienza mentre i nostri ingegneri lavorano per ripristinare la funzionalità. Se avete domande, contattate [email protected]

2. 20 agosto 2026 alle ore 01:04 UTCidentified

   Stiamo continuando a lavorare per risolvere questo problema.

3. 20 agosto 2026 alle ore 02:52 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

4. 20 agosto 2026 alle ore 03:05 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

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

   The issue has been identified and fix is being implemented.

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

   This incident has been resolved.

1. 22 luglio 2026 alle ore 08:03 UTCinvestigating

   Stiamo vivendo problemi con l'agente Mixpanel all'interno del webapp. Il nostro team di ingegneri è stato avvisato e sta indagando sul problema e lavorando per ripristinare la sua funzionalità. Apprezziamo la vostra pazienza mentre lavoriamo per risolvere questa questione. Se avete domande, si prega di contattare il supporto.

2. 22 luglio 2026 alle ore 09:52 UTCinvestigating

   il team continua a indagare sul problema e sui prossimi passi. Grazie per la pazienza.

3. 22 luglio 2026 alle ore 10:55 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

4. 22 luglio 2026 alle ore 14:47 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 11 luglio 2026 alle ore 07:53 UTCinvestigating

   Attualmente stiamo riscontrando ritardi nella nostra pipeline di ingestione dei dati, che sta influenzando i dati in tempo reale per i progetti iscritti nei progetti statunitensi, con conseguente ritardo per un sottoinsieme di progetti. Mentre nessun dato viene perso, il nostro team di ingegneri sta attivamente indagando sulla questione e lavorando per ripristinare la funzionalità in tempo reale il più rapidamente possibile. Apprezziamo la vostra pazienza in questo momento. Se avete domande, si prega di contattare il supporto.

2. 11 luglio 2026 alle ore 09:17 UTCinvestigating

   Stiamo continuando a indagare su questo problema.

3. 11 luglio 2026 alle ore 10:15 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

4. 11 luglio 2026 alle ore 12:54 UTCidentified

   Stiamo continuando a lavorare per risolvere questo problema.

5. 11 luglio 2026 alle ore 14:25 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

6. 11 luglio 2026 alle ore 15:54 UTCresolved

   Questo incidente è stato risolto.

7. 16 luglio 2026 alle ore 23:47 UTCpostmortem

   # Sommario Tra circa **11:35 PM PT il 10 luglio e 7:19 AM PT l'11 luglio 2026**, l'ingestione di dati per i progetti di Mixpanel nella regione degli Stati Uniti è stata alle spalle fino a ~2 ore. Durante questa finestra, report e dashboard mostrarono temporaneamente dati incompleti — gli intervalli di tempo recenti potrebbero apparire come forti, gocce artificiali in metriche come utenti attivi o entrate. ** Nessun dato è stato perso.** Tutti gli eventi sono stati in coda duramente ed elaborati in pieno una volta che il backlog ha cancellato; metriche restituito a valori accurati da soli, senza alcuna azione del cliente richiesta. La causa ha avuto origine nei nostri controlli di ingestione: per un piccolo numero di progetti molto ad alto volume, i tassi di ingestione che abbiamo permesso avevano abbandonato l'allineamento con la capacità prevista per tali progetti. Le grandi importazioni storiche — uso del tutto legittimo della piattaforma — sono state quindi ammesse più velocemente di quanto le loro infrastrutture potessero assorbire, e due proprietà del nostro gasdotto hanno trasformato quel sovraccarico localizzato in un ritardo a livello regionale. Le correzioni di seguito riallineano quei controlli in modo che qualsiasi importazione, di qualsiasi dimensione, venga automaticamente mantenuta entro limiti sicuri. # Che e' successo # La pipeline di ingestione di Mixpanel è sharded e multi-tenant: i dati di ogni progetto vengono distribuiti in un insieme di partizioni dimensionate per il suo volume atteso, e per throughput, gli eventi di molti clienti vengono elaborati insieme in lotti. Questo progetto offre un'alta efficienza, ma dipende da un invariante: il tasso in cui ammettiamo che il traffico di un progetto deve corrispondere alla capacità prevista per esso. Quando questo invariante regge, anche le importazioni molto grandi vengono assorbite senza intoppi. Qui, non ha tenuto. Un piccolo numero di grandissime importazioni di dati storici ha riguardato progetti i cui tassi di ingestione consentiti avevano, nel corso del tempo, superato la loro capacità di partizione prevista. Il volume in eccesso si concentrava su partizioni specifiche come **punti caldi**, saturando la porzione della flotta di streaming che li serviva. Due fattori hanno poi ampliato l'impatto: *** L'elaborazione in batch e multi-tenant ha amplificato i punti caldi.** Poiché gli eventi di molti clienti viaggiano insieme in lotti, lentezza e guasti sulle partizioni sovraccaricate hanno ritardato gli eventi dei clienti non correlati che condividono quei lotti. L'automatismo era inefficace. L'aggiunta di capacità non può dissolvere un punto caldo di questo tipo, perché le partizioni sovraccaricate rimangono fissate alla stessa infrastruttura, e un limite di capacità in un componente della nostra infrastruttura di streaming ha impedito la capacità aggiuntiva di prendere effetto. Insieme, questi hanno trasformato quello che avrebbe dovuto essere un breve, auto-guarigione rallentamento in un ritardo multi-ora che richiede l'intervento manuale. # Timeline \(Orario pacifico, luglio 10–11\) * **11:35 PM** — Avviso automatizzato rilevato il backlog di ingestione; ingegnere on-call impegnato immediatamente. * **12:49 AM** — Incidente della pagina di stato pubblicato; impatto portata solo alla regione degli Stati Uniti. Revisione: La più grande importazione di contributo è stata interrotta. * **1:55–6:48 ** — Rimozioni progressive: fonti di traffico addizionali accelerate, alcuni dati arretrati differiti con l'accordo del cliente proprietario, l'isolamento di guasto abilitato nella pipeline e nodi infrastrutturali colpiti sostituiti. * **7:19 AM** — Backlog completamente elaborato; tutti i progetti attuali. Pagina di stato spostato al monitoraggio, quindi risolto dopo un periodo di osservazione stabile. # Root cause # 1. ** I limiti del tasso di ingestione sono disallineati con capacità provvista.** Per i progetti di guida, i tassi che la nostra piattaforma ha ammesso erano cresciuti fuori passo con l'infrastruttura fornita per loro, così legittime importazioni ad alto volume sono state lasciate in più veloce che le loro partizioni potrebbero assorbire. Questa è la causa della radice sistemica. Le importazioni stesse erano un uso legittimo della piattaforma. 2. ** L'elaborazione in batch e multi-tenant ha amplificato il sovraccarico.** I guasti sulle partizioni sovraccaricate hanno ritardato gli eventi dei clienti non correlati condividendo gli stessi lotti di elaborazione, diffondendo un problema localizzato in tutta la piattaforma. 3. **Traffico alle partizioni sovraccarica non può essere ridistribuita.** L'assegnazione di partizione-server nello strato di streaming non era a carico, in modo che i punti caldi sono stati bloccati agli stessi server indipendentemente dalla dimensione della flotta — la capacità totale era sufficiente, ma non poteva essere portato a sopportare. Un limite di scaling in un componente della nostra infrastruttura di streaming ha composto questo impedendo scala-up di aggiungere la capacità, che ha ritardato la diagnosi fino a quando gli ingegneri sono intervenuti manualmente. # Quello che stiamo cambiando # Lo stato finale che stiamo costruendo verso: ** tutti i limiti di ingestione del progetto corrispondono automaticamente alla sua capacità provvista, in modo che le importazioni di qualsiasi dimensione, tra cui pieno storico backfill e sincronizza di data warehouse, possono funzionare senza coordinamento anticipato, e il volume di un progetto è impedito di influenzare la freschezza dei dati di un altro**. Già dispiegato — migliorare la nostra gestione dell'ingestione: ***Migliorato trattamento hot-spot * La distribuzione del traffico nello strato di streaming è ora consapevole del carico, diffondendo il carico concentrato più uniformemente attraverso la flotta, e i singoli elementi di problema sono ora recuperati separatamente invece di tenere il resto del loro lotto — riducendo, anche se non eliminando, l'impatto che un sovraccarico localizzato può avere sul traffico non correlato. ***I carichi di lavoro a volume più elevato sono stati ripresi su infrastrutture di dimensioni adeguate, prioritarie dal rischio. Già implementato — modificando il funzionamento del servizio di streaming di terze parti: *** Audited e ri-tuned il profilo di capacità della flotta** così i singoli server hanno sostanzialmente più headroom per il carico concentrato, e hanno lavorato con il fornitore per risolvere la limitazione di scala incontrata durante l'incidente. In corso: * ** Limitamento del tasso di capacità-consapevole ** — chiusura delle lacune tra i limiti di tasso di progetto individualmente concessi e la capacità reale di ciascun progetto, estendendo il tasso di limitazione ai percorsi di ingestione che in precedenza lo mancavano, e accoppiando qualsiasi aumento di limite futuro ad un aumento di capacità, che è progettato per impedire a questa classe di disallineamento di ricorsi. * ** Monitoraggio e allerta del volume incisi al motore** così il disallineamento della capacità viene rilevato e corretto prima che possa influenzare qualsiasi cliente. * Valutazione dell'isolamento del carico di lavoro più forte / priorità di recupero del backlog per i percorsi di traffico di rinfuse / backfill, così le importazioni storiche hanno ridotto l'impatto sul traffico dal vivo # Domande comuni # # Ci sono dati persi? # No. Gli eventi sono stati duramente in coda durante l'incidente e sono stati completamente elaborati una volta che il backlog è stato cancellato. Qualsiasi goccia metrica vista durante la finestra era un artefatto di visualizzazione del ritardo e autocorretto. *** Devo coordinare grandi importazioni o backfill con Mixpanel?** No. Il nostro obiettivo è per la piattaforma di mantenere automaticamente qualsiasi importazione entro i tassi di sicurezza, in modo che backfill e sincronizzazioni di magazzino possono funzionare senza pianificazione o preavviso. Stiamo ancora esaurendo i controlli di capacità-consapevoli che forniscono questo. Nel frattempo, se si sta pianificando un'importazione insolitamente grande o backfill, si consiglia di coordinare con il vostro team account in modo da poter confermare la capacità in anticipo. # Come puo' andare avanti? # La fissazione sistemica sta stringendo le lacune tra i limiti di tasso di progetto individualmente concessi e la capacità reale di ciascun progetto, e l'estensione del tasso limitante ai percorsi di ingestione che in precedenza lo mancavano — così il sovraccarico di questo tipo viene interrotto all'ammissione. Inoltre, la limitazione di scaling che ha prolungato l'incidente è fissato, il gasdotto ora recupera singoli elementi di problema separatamente in modo che un sovraccarico localizzato ha molto meno impatto sul traffico non correlato, e il traffico di massa è ulteriormente isolato dal traffico dal vivo. *** I progetti individuali possono essere prioritari durante il recupero?** Questa capacità non esisteva durante l'incidente — tutti i progetti recuperati allo stesso ritmo. Stiamo valutando i meccanismi di priorità per il recupero del backlog come parte del nostro lavoro di follow-up. Ci scusiamo per la rottura e per la preoccupazione le metriche temporaneamente depresse causate. Si prega di raggiungere attraverso il vostro team di account o il supporto con qualsiasi domanda.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 29 giugno 2026 alle ore 19:47 UTCinvestigating

   Mixpanel sta sperimentando le prestazioni degradate con la nostra API Query, inclusa la latenza aumentata. È possibile visualizzare rapporti di carico lento o errori di query. Apprezziamo la vostra pazienza mentre i nostri ingegneri lavorano per ripristinare la normale funzionalità. pubblicheremo aggiornamenti sui progressi nella nostra pagina di stato. Se avete domande, si prega di contattare il supporto.

2. 29 giugno 2026 alle ore 21:04 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 29 giugno 2026 alle ore 22:42 UTCidentified

   La latenza di query si è stabilizzata, anche se il nostro team continua a indagare sulla causa sottostante delle prestazioni degradate. Continueremo a pubblicare aggiornamenti mentre la nostra indagine progredisce. Grazie per la pazienza.

4. 30 giugno 2026 alle ore 02:15 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

5. 30 giugno 2026 alle ore 03:30 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

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

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

3. 3 giugno 2026 alle ore 21:27 UTCresolved

   This incident has been resolved.

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

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

3. 2 giugno 2026 alle ore 14:31 UTCmonitoring

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

4. 2 giugno 2026 alle ore 16:53 UTCresolved

   This incident has been resolved.

1. 1 giugno 2026 alle ore 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 giugno 2026 alle ore 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 giugno 2026 alle ore 15:29 UTCidentified

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

4. 1 giugno 2026 alle ore 16:38 UTCmonitoring

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

5. 1 giugno 2026 alle ore 19:42 UTCresolved

   This incident has been resolved.

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

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

4. 19 maggio 2026 alle ore 21:18 UTCresolved

   This incident has been resolved.

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

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

3. 15 maggio 2026 alle ore 10:19 UTCidentified

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

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

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

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

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

13. 16 maggio 2026 alle ore 02:50 UTCresolved

    This incident has been resolved.

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

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

2. 13 maggio 2026 alle ore 21:40 UTCidentified

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

3. 14 maggio 2026 alle ore 13:35 UTCresolved

   This incident has been resolved.

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

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

3. 12 maggio 2026 alle ore 20:24 UTCmonitoring

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

4. 12 maggio 2026 alle ore 21:44 UTCresolved

   This incident has been resolved.

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

   This incident has been resolved.

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

   This incident has been resolved.

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

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

3. 16 marzo 2026 alle ore 21:47 UTCresolved

   This incident has been resolved.

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

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

3. 2 marzo 2026 alle ore 21:09 UTCmonitoring

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

4. 2 marzo 2026 alle ore 21:53 UTCresolved

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