Degraded Query API Performance che colpisce i progetti statunitensi
Inizio 26 agosto 2026 alle ore 21:39 UTC · 1h 7m
OutageIncidente maggiore
Componenti interessati
Application Availability (US)
investigating
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.
identified
Il problema è stato identificato e si sta attuando una correzione.
monitoring
Una correzione è stata implementata, e stiamo vedendo migliori tassi di successo per l'API di Query. Continueremo a monitorare per garantire la stabilità.
resolved
Questo incidente è stato risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
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]
identified
Stiamo continuando a lavorare per risolvere questo problema.
monitoring
Una soluzione è stata implementata e stiamo monitorando i risultati.
resolved
Questo incidente è stato risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
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.
Problemi di risposta da parte dell'agente Mixpanel
Inizio 22 luglio 2026 alle ore 08:03 UTC · 6h 44m
Pending
investigating
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.
investigating
il team continua a indagare sul problema e sui prossimi passi. Grazie per la pazienza.
monitoring
Una soluzione è stata implementata e stiamo monitorando i risultati.
resolved
Questo incidente è stato risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Delay temporaneo di ingestione dei dati per i progetti statunitensi
Inizio 11 luglio 2026 alle ore 07:53 UTC · 8h 1m
IssuesIncidente minore
Componenti interessati
Ingestion API Availability (US)
investigating
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.
investigating
Stiamo continuando a indagare su questo problema.
identified
Il problema è stato identificato e si sta attuando una correzione.
identified
Stiamo continuando a lavorare per risolvere questo problema.
monitoring
Una soluzione è stata implementata e stiamo monitorando i risultati.
resolved
Questo incidente è stato risolto.
postmortem
# 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.
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.
identified
Il problema è stato identificato e si sta attuando una correzione.
identified
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.
monitoring
Una soluzione è stata implementata e stiamo monitorando i risultati.
resolved
Questo incidente è stato risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Issue with Inviting and Deleting Users
Inizio 3 giugno 2026 alle ore 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
Inizio 2 giugno 2026 alle ore 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
Inizio 19 maggio 2026 alle ore 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
Inizio 14 maggio 2026 alle ore 23:17 UTC · 1d 3h
IssuesIncidente minore
Componenti interessati
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
Inizio 13 maggio 2026 alle ore 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
Inizio 12 maggio 2026 alle ore 17:17 UTC · 3h 57m
Pending
Componenti interessati
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
Inizio 6 maggio 2026 alle ore 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
Inizio 9 aprile 2026 alle ore 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
Inizio 16 marzo 2026 alle ore 16:50 UTC · 4h 56m
IssuesIncidente minore
Componenti interessati
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
Inizio 2 marzo 2026 alle ore 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.
Degraded MCP Availability
Inizio 2 marzo 2026 alle ore 19:37 UTC · 6h 5m
Pending
investigating
A subset of users are experiencing OAuth issues when connecting to our MCP server. We are currently investigating this issue.
identified
The issue has been identified and a fix is being implemented.
monitoring
A fix has been implemented and we are monitoring the results.
monitoring
We have partially mitigated the issue and are continuing to monitor for any further impact. We are also actively working to address the root cause.
resolved
This incident has been resolved.
Degraded MCP Availability
Inizio 2 marzo 2026 alle ore 18:02 UTC · 37m
Pending
investigating
A subset of users are experiencing OAuth issues when connecting to our MCP server. We are currently investigating this issue.
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 is resolved.
Delays with Integrations Syncs (Cohort Exports)
Inizio 30 gennaio 2026 alle ore 18:39 UTC · 8h 2m
Pending
Componenti interessati
Data Export
investigating
We are currently experiencing delays with Cohort Syncs to external destinations, including custom webhooks and engagement platforms. Our team is investigating the issue and actively working on a resolution. We sincerely apologize for the inconvenience and thank you for your kind understanding.
If you have any questions, please contact support
monitoring
A fix has been implemented, and we are monitoring the results. Recurring cohort syncs should resume on the next scheduled run with no additional action required.
monitoring
We are continuing to monitor for further issues. We have identified that a subset of Cohort Syncs are still experiencing delays and are working to resolve these remaining cases.
monitoring
Additional fixes have been implemented. We are continuing to monitor for any further issues.
resolved
This incident has been resolved.
Cronologia delle interruzioni di Mixpanel | Uptimus