Historique des pannes de Mixpanel

1. 26 août 2026 à 21:39 UTCinvestigating

   Mixpanel connaît des performances de l'API Query dégradées, ce qui entraîne des réponses HTTP 500 lors de la requête de rapports pour des projets avec US Data Residency. Les projets avec l'UE et IN Data Residency restent inchangés. Nous apprécions votre patience pendant que nos ingénieurs travaillent à restaurer une fonctionnalité normale. Nous afficherons des mises à jour sur notre page d'état. Si vous avez des questions, veuillez contacter le support.

2. 26 août 2026 à 22:11 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 26 août 2026 à 22:28 UTCmonitoring

   Un correctif a été mis en place, et nous constatons des taux de succès améliorés pour l'API Query. Nous continuerons de surveiller pour assurer la stabilité.

4. 26 août 2026 à 22:45 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 19 août 2026 à 23:20 UTCidentified

   Nous rencontrons actuellement des problèmes avec les propriétés populantes des événements dans les menus déroulants. Nous apprécions votre patience pendant que nos ingénieurs travaillent à restaurer la fonctionnalité. Si vous avez des questions, veuillez contacter [email protected]

2. 20 août 2026 à 01:04 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

3. 20 août 2026 à 02:52 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 20 août 2026 à 03:05 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 6 août 2026 à 07:19 UTCinvestigating

   Nous sommes conscients que l'outil Get-Report du serveur MCP Mixpanel échoue actuellement lorsqu'il est appelé avec skip results: false. Les métadonnées des rapports ne sont pas affectées. Nous enquêtons sur la question et fournirons des mises à jour comme nous les avons.

2. 6 août 2026 à 08:39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 6 août 2026 à 09:12 UTCmonitoring

   A fix has been deployed and we're now monitoring the results. Report queries in the Mixpanel MCP server should be functioning normally. We'll continue to watch closely and provide a final update once we've confirmed full resolution.

4. 6 août 2026 à 13:32 UTCresolved

   This incident has been resolved.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 juillet 2026 à 08:03 UTCinvestigating

   Nous rencontrons actuellement des problèmes avec l'agent Mixpanel dans le webapp. Notre équipe d'ingénieurs a été alertée et étudie la question et travaille à restaurer sa fonctionnalité. Nous apprécions votre patience dans nos efforts pour résoudre cette question. Si vous avez des questions, veuillez contacter le support.

2. 22 juillet 2026 à 09:52 UTCinvestigating

   l'équipe continue d'étudier la question et les prochaines étapes. Merci de votre patience.

3. 22 juillet 2026 à 10:55 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

4. 22 juillet 2026 à 14:47 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 11 juillet 2026 à 07:53 UTCinvestigating

   Nous sommes actuellement confrontés à des retards dans notre pipeline d'ingestion de données, qui affecte les données en temps réel pour les projets inscrits dans les projets américains, entraînant des retards pour un sous-ensemble de projets. Bien qu'aucune donnée ne soit perdue, notre équipe d'ingénieurs étudie activement la question et s'emploie à restaurer la fonctionnalité en temps réel le plus rapidement possible. Nous apprécions votre patience pendant cette période. Si vous avez des questions, veuillez contacter le support.

2. 11 juillet 2026 à 09:17 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 11 juillet 2026 à 10:15 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 11 juillet 2026 à 12:54 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

5. 11 juillet 2026 à 14:25 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

6. 11 juillet 2026 à 15:54 UTCresolved

   Cet incident a été résolu.

7. 16 juillet 2026 à 23:47 UTCpostmortem

   # Résumé Entre environ **11:35 PM PT le 10 Juillet et 7:19 PM PT le 11 Juillet, 2026**, l'ingestion de données pour les projets de Mixpanel dans la région des États-Unis a duré jusqu'à ~2 heures. Au cours de cette fenêtre, les rapports et les tableaux de bord présentaient temporairement des données incomplètes — des intervalles de temps récents pourraient apparaître comme des baisses artificielles et pointues dans des mesures telles que les utilisateurs actifs ou les revenus. **Aucune donnée n'a été perdue.** Tous les événements ont été tenus en file d'attente et traités en totalité une fois l'arriéré réglé; les mesures sont retournées à des valeurs précises par elles-mêmes, sans aucune action du client. La cause est née de notre contrôle de l'ingestion : pour un petit nombre de projets à très fort volume, les taux d'ingestion que nous avons autorisés avaient diminué par rapport à la capacité prévue pour ces projets. Les grandes importations historiques — utilisation tout à fait légitime de la plate-forme — ont donc été admises plus rapidement que leur infrastructure ne pouvait absorber, et deux propriétés de notre pipeline ont transformé cette surcharge localisée en un retard dans toute la région. Les corrections ci-dessous réaligner ces contrôles de sorte que toute importation, quelle que soit sa taille, soit automatiquement maintenue dans des limites sûres. Que s'est-il passé ? Le pipeline d'ingestion de Mixpanel est strié et multi-tenu : les données de chaque projet sont distribuées sur un ensemble de partitions dimensionnées pour son volume attendu, et pour le débit, les événements de nombreux clients sont traités en lots. Cette conception offre une grande efficacité, mais elle dépend d'un invariant: le taux auquel nous admettons le trafic d'un projet doit correspondre à la capacité prévue pour lui. Lorsque cet invariant tient, même de très grandes importations sont absorbées sans heurt. Ici, il ne tenait pas. Un petit nombre de très grandes importations de données historiques ont eu lieu dans le cadre de projets dont les taux d'ingestion autorisés avaient, au fil du temps, augmenté bien au-delà de leur capacité de partition fournie. L'excès de volume s'est concentré sur des partitions spécifiques comme **points chauds**, saturant la portion de la flotte qui les dessert. Deux facteurs ont ensuite élargi l'impact: * **Un traitement multi-tenancier a amplifié les points chauds.** Parce que les événements de nombreux clients voyagent ensemble en lots, la lenteur et les échecs sur les partitions surchargées ont retardé les événements des clients indépendants partageant ces lots. * **La mise à niveau automatique était inefficace**. L'ajout de capacité ne peut pas dissoudre un point chaud de ce type, car les cloisons surchargées restent coincées à la même infrastructure, et une limite de capacité dans une composante de notre infrastructure de streaming a empêché la capacité supplémentaire de prendre effet. Ensemble, ils ont transformé ce qui aurait dû être un bref ralentissement de l'auto-guérison en un délai de plusieurs heures nécessitant une intervention manuelle. # Chronologie \(Heure du Pacifique, 10-11 juillet\) * **11:35 PM** — L'alerte automatisée a détecté l'arriéré d'ingestion; un ingénieur de garde s'est engagé immédiatement. * **12:49 AM** — L'incident de la page d'état a été affiché; l'impact a été porté uniquement à la région américaine. * **1:23 L'importation la plus importante a été interrompue. * **1:55–6:48** — Atténuations progressives: des sources de trafic supplémentaires ont assombri, certaines données en retard ont été reportées avec l'accord du client propriétaire, l'isolement de défaillance a été activé dans le pipeline et les nœuds d'infrastructure touchés ont été remplacés. * **7:19 AM** — Backlog entièrement traité; tous les projets en cours. La page d'état a été déplacée vers la surveillance, puis résolue après une période d'observation stable. Cause profonde 1. ** Limites de taux d ' ingestion désalignées avec la capacité fournie.** Pour les projets d'entraînement, les taux admis par notre plate-forme avaient augmenté en fonction de l'infrastructure fournie pour eux, de sorte que les importations légitimes à volume élevé ont été laissées en place plus rapidement que leurs cloisons ne pouvaient absorber. C'est la cause fondamentale systémique. Les importations elles-mêmes étaient une utilisation légitime de la plate-forme. 2. **Un traitement multi-teneurs assorti amplifie la surcharge**. Les défaillances des partitions surchargées ont retardé les événements de clients indépendants partageant les mêmes lots de traitement, répartissant un problème localisé sur toute la plateforme. 3. **La circulation vers les partitions surchargées ne peut être redistribuée**. L'affectation de la partition vers le serveur dans la couche de streaming n'était pas mise en veille, de sorte que les points chauds sont restés coincés sur les mêmes serveurs indépendamment de la taille de la flotte — la capacité totale était suffisante, mais elle ne pouvait pas être portée à l'eau. Une limite d'échelle dans une composante de notre infrastructure de streaming a aggravé cela en empêchant l'augmentation d'échelle de la capacité, ce qui a retardé le diagnostic jusqu'à ce que les ingénieurs interviennent manuellement. Ce que nous changeons L'état final vers lequel nous nous dirigeons : **les limites d'ingestion de chaque projet correspondent automatiquement à sa capacité fournie, de sorte que les importations de toute taille, y compris les remblayages historiques complets et les synchronisations des entrepôts de données, peuvent fonctionner sans coordination préalable, et le volume d'un projet est empêché d'affecter la fraîcheur des données d'un autre.**. Déjà déployé — améliorer notre manipulation de l'ingestion: * ** Amélioration de la manipulation des points chauds.** La distribution du trafic dans la couche de streaming est maintenant consciente de la charge, répartissant la charge concentrée plus uniformément dans la flotte, et les éléments de problème individuels sont maintenant réétudiés séparément au lieu de retenir le reste de leur lot — réduisant, mais non éliminant, l'impact d'une surcharge localisée sur le trafic non lié. * **Réaménagé les charges de travail les plus élevées** sur des infrastructures de taille appropriée, classées par risque. Déjà déployé — changer la façon dont nous exploitons le service de streaming tiers: * **Audité et réajusté le profil de capacité de la flotte** de sorte que les serveurs individuels ont beaucoup plus de salle de tête pour les charges concentrées, et travaillé avec le fournisseur pour résoudre la limitation d'échelle rencontrée pendant l'incident. En cours: * ** Limite de la capacité** — Combler l'écart entre les limites de taux accordées individuellement et la capacité réelle fournie de chaque projet, étendre la limite de taux aux voies d'ingestion qui ne l'étaient pas auparavant, et combiner toute augmentation future de la capacité à une augmentation de la capacité, qui est conçue pour éviter que cette catégorie de désalignement ne se répète. * **Surveiller et alerter le volume à grain fin** afin de détecter et de corriger un désalignement de capacité avant qu'il puisse affecter n'importe quel client. * Évaluer l'isolement de la charge de travail et la priorité de récupération des dossiers pour les voies de trafic en vrac et de remplissage, de sorte que les importations historiques ont réduit l'impact sur le trafic en direct # Questions communes * **Est-ce que des données ont été perdues?** Non. Les événements ont été en attente pendant tout l'incident et ont été traités une fois l'arriéré réglé. Toutes les gouttes métriques vues pendant la fenêtre étaient un artefact d'affichage du retard et autocorrigées. * **Dois-je coordonner les grandes importations ou les remblayages avec Mixpanel?** Numéro Notre objectif est que la plate-forme conserve automatiquement toute importation dans des taux de sécurité, de sorte que les remblayages et les synchronisations d'entrepôt puissent fonctionner sans programmation ni préavis. Nous sommes toujours en train de mettre en place les contrôles de capacité qui permettent de le faire. En attendant, si vous planifiez une importation ou un remblayage exceptionnellement important, nous vous recommandons de coordonner avec votre équipe de compte afin que nous puissions confirmer la capacité à l'avance. * **Comment cela est-il empêché d'aller de l'avant?** La solution systémique consiste à resserrer les écarts entre les limites de taux accordées individuellement et la capacité réelle fournie de chaque projet, et à étendre le taux de limitation aux voies d'ingestion qui ne l'étaient pas auparavant. De plus, la limitation de l'échelle qui a prolongé l'incident est fixée, le pipeline récupère maintenant les différents éléments de problème séparément de sorte qu'une surcharge localisée a beaucoup moins d'impact sur le trafic non lié, et le trafic en vrac est encore plus isolé du trafic en direct. * **Les projets individuels peuvent-ils être prioritaires pendant le rétablissement?** Cette capacité n'existait pas pendant l'incident — tous les projets ont été récupérés au même rythme. Nous évaluons les mécanismes d'établissement des priorités pour le recouvrement des arriérés dans le cadre de nos travaux de suivi. Nous nous excusons de la perturbation et de l'inquiétude que suscitent les mesures temporairement déprimées. Veuillez contacter votre équipe de compte ou votre support pour toute question.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 29 juin 2026 à 19:47 UTCinvestigating

   Mixpanel connaît des performances dégradées avec notre API Query, y compris une latence accrue. Vous pouvez voir des rapports de chargement lent ou des erreurs de requête. Nous apprécions votre patience pendant que nos ingénieurs travaillent à restaurer une fonctionnalité normale. Nous afficherons des mises à jour sur notre page d'état. Si vous avez des questions, veuillez contacter le support.

2. 29 juin 2026 à 21:04 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 29 juin 2026 à 22:42 UTCidentified

   La latence des requêtes s'est stabilisée, bien que notre équipe continue d'étudier la cause sous-jacente de la performance dégradée. Nous continuerons de publier des mises à jour au fur et à mesure que notre enquête progressera. Merci de votre patience.

4. 30 juin 2026 à 02:15 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 30 juin 2026 à 03:30 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 3 juin 2026 à 20:05 UTCinvestigating

   Mixpanel is currently experiencing a disruption in the ability to invite and delete internal users within organizations. We appreciate your patience while our engineers work to restore this functionality. If you have any questions, please contact [email protected]

2. 3 juin 2026 à 20:17 UTCidentified

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

3. 3 juin 2026 à 21:27 UTCresolved

   This incident has been resolved.

1. 2 juin 2026 à 11:02 UTCinvestigating

   We are experiencing delays with our data ingestion and shuffling pipeline to projects with all projects. No data is being lost but as a result, real-time data is delayed. We appreciate your patience while our engineers work to restore real-time functionality. If you have any questions, please contact support

2. 2 juin 2026 à 12:31 UTCidentified

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

3. 2 juin 2026 à 14:31 UTCmonitoring

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

4. 2 juin 2026 à 16:53 UTCresolved

   This incident has been resolved.

1. 1 juin 2026 à 14:15 UTCinvestigating

   We are experiencing delays with our data ingestion and shuffling pipeline to projects with US & India data residency. No data is being lost but as a result, real-time data is delayed. We appreciate your patience while our engineers work to restore real-time functionality. If you have any questions, please contact support

2. 1 juin 2026 à 15:08 UTCinvestigating

   We have now identified an ingestion delay for EU projects, and are continuing to investigate the issue. Thank you for your patience.

3. 1 juin 2026 à 15:29 UTCidentified

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

4. 1 juin 2026 à 16:38 UTCmonitoring

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

5. 1 juin 2026 à 19:42 UTCresolved

   This incident has been resolved.

1. 19 mai 2026 à 19:03 UTCinvestigating

   A subset of users are currently facing issues accessing boards that they previously had access to view. Our Engineering team is actively investigating and will update shortly.

2. 19 mai 2026 à 19:10 UTCidentified

   The issues has been identified and a fix is being implemented. As a workaround boards can be explicitly shared with users who are having issues viewing them currently.

3. 19 mai 2026 à 20:23 UTCmonitoring

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

4. 19 mai 2026 à 21:18 UTCresolved

   This incident has been resolved.

1. 14 mai 2026 à 23:17 UTCinvestigating

   We are experiencing degraded performance with our Query API, including increased latency. You may see slow-loading reports, incomplete query results, query errors, or data discrepancies. We appreciate your patience while our engineers work to restore normal functionality. We will post progress updates on our status page. If you have any questions, please contact support.

2. 14 mai 2026 à 23:48 UTCidentified

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

3. 15 mai 2026 à 10:19 UTCidentified

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

4. 15 mai 2026 à 12:28 UTCidentified

   We've continued to make progress on the issue affecting some US projects. Query success rates have returned to normal levels, and the related processing delays have also recovered. A subset of affected projects may still see incomplete data in query results while our recovery process runs. We're actively working on this and will share another update in 2 hours. Impact remains limited to our US region. We do not currently believe any data has been permanently lost.

5. 15 mai 2026 à 14:31 UTCidentified

   Recovery is progressing well. Query success rates remain at normal levels, and missing data has now been restored for a portion of affected projects. We're continuing the recovery process for the remaining affected projects and currently estimate full recovery within approximately 3–5 hours. Some customers may still see incomplete data in query results until this work is complete.

6. 15 mai 2026 à 16:37 UTCidentified

   We are continuing to work on resolving this issue. Our current estimate for full recovery is approximately 3–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

7. 15 mai 2026 à 18:47 UTCidentified

   Recovery is continuing to progress and query latency has returned to normal levels. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

8. 15 mai 2026 à 19:56 UTCidentified

   We are investigating an increase in query latency that appears to be unrelated to the ongoing recovery. You may experience slower-loading reports. Our team is actively looking into the cause and we will provide an update shortly. Recovery is continuing to progress. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

9. 15 mai 2026 à 21:23 UTCidentified

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

10. 15 mai 2026 à 22:14 UTCidentified

    Query latency has returned to normal levels and has been resolved. Recovery is continuing to progress, and our current estimate for full recovery is approximately 4–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

11. 16 mai 2026 à 00:17 UTCidentified

    Recovery is continuing to progress. Our current estimate for full recovery is approximately 1-2 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.

12. 16 mai 2026 à 01:52 UTCmonitoring

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

13. 16 mai 2026 à 02:50 UTCresolved

    This incident has been resolved.

14. 21 mai 2026 à 21:43 UTCpostmortem

    # Mixpanel RCA: Transient Data Access Issue, May 14, 2026 ## Summary On Thursday, May 14, 2026 at approximately 2:30 PM PT, a routine but infrequent cleanup operation in Mixpanel's storage system mistakenly removed a portion of production data files in addition to the unused files it was intended to remove. Some customers experienced query errors during the hours that followed. We detected the issue within minutes, deployed mitigations the same evening that returned query success rates and latency to normal, and restored the affected files from backup by 5:15 PM PT on Friday, May 15. Mixpanel's ingestion pipeline was not affected and no event data was lost in transit. ## What happened This incident was triggered by a storage cleanup procedure that runs periodically to remove files no longer referenced by Mixpanel's metadata. The procedure was more involved than usual: it followed a recent enhancement to our file storage strategy that left a set of unused files behind in our storage backend, and addressing them required extending our standard cleanup approach to cover a new code path. As part of executing this extended cleanup, an engineer generated the list of files to delete using a SQL query whose date filter was not strictly earlier than the reference snapshot it was being compared against. As a result, a small set of legitimate production files that had been written in the gap window between the snapshot and the filter date were incorrectly classified as unused and removed. The deletion ran for roughly half an hour before internal alerting caught the resulting query failures and the operation was stopped. The trigger was operator error against an ambiguous runbook, not a defect in the live serving path or in our ingestion pipeline. ## Customer impact Impact unfolded in two phases. The first phase ran from Thursday at approximately 2:30 PM PT until 8:11 PM PT — roughly five and a half hours. During this window, customers across the platform may have seen slower or failed queries when their requests touched files that had been deleted. The breadth and severity varied by project depending on which data each query touched. By 8:11 PM PT, mitigations had fully rolled out — queries automatically retried against an alternate availability zone, and a fallback path was put in place to serve missing files from a backup datastore. After this point, query success rate and latency returned to normal. The second phase lasted from 8:11 PM PT Thursday through approximately 5:15 PM PT Friday, May 15. During this window, fewer than 2% of customers were still affected — specifically, those whose deleted files had not yet been fully restored from backup. The vast majority of these files were recovered by Friday afternoon. A small number of projects \(under 30\) had files that could not be fully recovered from backup, and we are following up with those accounts directly. ## Timeline \(Pacific Time\) * May 14, 2:30 PM — Cleanup operation begins * May 14, 3:11 PM — Internal alerting flags query failures; the cleanup operation is stopped within minutes * May 14, 4:07 PM — Status page banner posted * May 14, 4:45 PM — Mitigation deployed: queries automatically retry against an alternate availability zone * May 14, 7:12 PM — Mitigation deployed: queries fall back to a backup datastore for missing files * May 14, 8:11 PM — Query success rate and latency fully restored to normal levels * May 15, 5:15 PM — File restore from backup complete; status page banner resolved ## Why this happened Several contributing factors lined up. The runbook for this cleanup procedure had ambiguous wording around the ordering and timing of its inputs. It had been recently authored to handle the new file-storage code path and had not gone through a formal review before being used. Our cleanup tooling did not programmatically enforce the safety invariant that the date filter must be strictly before the reference snapshot. That invariant lived only in operator-authored SQL. The extended cleanup was being executed in parallel across two storage layers by two different engineers, which increased the room for error. ## What we're doing to prevent recurrence We have already made or have actively in flight the following changes. We are adding programmatic safeguards to our cleanup tooling so that an input set whose date filter is not safely before the reference snapshot is rejected before any deletion occurs, along with a reconciliation step that flags any production-referenced file before deletion proceeds. Destructive cleanup operations will now run in phased stages, starting with internal projects and pausing for a holding period before any broader execution. Destructive storage operations now require a second engineer to sign off on the exact deletion set and to be present during execution, matching the practice we already follow for database migrations. We have updated the cleanup runbook with explicit guidance on input timing, required safety buffers, and an enforced review process for any runbook covering a destructive operation. Longer term, we are working to eliminate the manual portion of this cleanup procedure entirely and route it through our existing automated cleanup infrastructure, so the class of failure that produced this incident is no longer reachable through human input. ## Closing Reliability and data integrity are foundational to the trust our customers place in Mixpanel, and we recognize the impact this incident had on the teams who rely on us. We are sorry for the disruption. If you have questions about how this incident may have affected a specific project, please reach out to your account team or Mixpanel Support.

1. 13 mai 2026 à 16:34 UTCidentified

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

2. 13 mai 2026 à 21:40 UTCidentified

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

3. 14 mai 2026 à 13:35 UTCresolved

   This incident has been resolved.

1. 12 mai 2026 à 17:45 UTCinvestigating

   We are currently investigating an issue that leads to degraded performance of Data Volume Monitoring in a subset of US-based projects. We truly appreciate your patience and apologize for the inconvenience. If you have any questions, please contact support (https://mixpanel.com/get-support).

2. 12 mai 2026 à 17:46 UTCidentified

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

3. 12 mai 2026 à 20:24 UTCmonitoring

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

4. 12 mai 2026 à 21:44 UTCresolved

   This incident has been resolved.

1. 6 mai 2026 à 00:00 UTCinvestigating

   A subset of projects are experiencing issues exporting data to the Snowflake warehouse via Mixpanel pipelines. We are currently investigating this issue.

2. 6 mai 2026 à 09:32 UTCidentified

   We have identified the issue affecting Snowflake pipeline exports for a subset of projects, and our engineering team is working on a resolution.

3. 6 mai 2026 à 20:04 UTCresolved

   This incident has been resolved.

1. 9 avril 2026 à 20:03 UTCidentified

   We are currently experiencing an interruption with our credit card processing. Our engineers have identified the issue and are working on a fix.

2. 9 avril 2026 à 21:00 UTCmonitoring

   A fix has been deployed, and all impacted accounts have had their billing re-run. If you continue to receive errors, please ensure the card on file is up to date. If you are still experiencing issues, please submit a support ticket.

3. 9 avril 2026 à 21:44 UTCresolved

   This incident has been resolved.

1. 16 mars 2026 à 16:50 UTCidentified

   Mixpanel is experiencing increased query latency for projects with EU residency, which may result in HTTP 500 responses when querying or saving reports. Projects with US and IN residency remain unaffected. Our engineering team is working on a resolution.

2. 16 mars 2026 à 19:29 UTCmonitoring

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

3. 16 mars 2026 à 21:47 UTCresolved

   This incident has been resolved.

1. 2 mars 2026 à 21:00 UTCinvestigating

   We are currently experiencing issues with loading Mixpanel.com and are working to restore service as quickly as possible. Our team is investigating the issue and will provide updates as soon as we have more information. Thank you for your patience.

2. 2 mars 2026 à 21:09 UTCidentified

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

3. 2 mars 2026 à 21:09 UTCmonitoring

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

4. 2 mars 2026 à 21:53 UTCresolved

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

1. 2 mars 2026 à 19:48 UTCinvestigating

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

2. 2 mars 2026 à 19:49 UTCidentified

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

3. 2 mars 2026 à 19:50 UTCmonitoring

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

4. 2 mars 2026 à 20:08 UTCmonitoring

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

5. 3 mars 2026 à 01:43 UTCresolved

   This incident has been resolved.

1. 2 mars 2026 à 18:41 UTCinvestigating

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

2. 2 mars 2026 à 18:44 UTCidentified

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

3. 2 mars 2026 à 18:45 UTCmonitoring

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

4. 2 mars 2026 à 18:53 UTCresolved

   This incident is resolved.

1. 30 janvier 2026 à 18:39 UTCinvestigating

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

2. 30 janvier 2026 à 20:05 UTCmonitoring

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

3. 30 janvier 2026 à 22:14 UTCmonitoring

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

4. 31 janvier 2026 à 01:48 UTCmonitoring

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

5. 31 janvier 2026 à 02:41 UTCresolved

   This incident has been resolved.