Historique des pannes de Mixpanel

1. 21 octobre 2026 à 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 octobre 2026 à 20:15 UTCresolved

   This incident has been resolved.

1. 21 octobre 2026 à 22:28 UTCmonitoring

   Nous avons reçu des rapports que les demandes de decision.mixpanel.com échouent. Tout trafic envoyé par decision.mixpanel.com peut être affecté, y compris les drapeaux de fonction et le suivi des événements. Pour restaurer le service maintenant, les requêtes point à api.mixpanel.com (US), api-eu.mixpanel.com (EU), ou api-in.mixpanel.com (IN), selon la résidence de données de votre projet. Nous avons déployé une atténuation et sommes en train de surveiller les résultats. Nous voyons la circulation rétablie. Nous afficherons des mises à jour sur notre page d'état. Si vous avez des questions, veuillez contacter le support.

2. 22 octobre 2026 à 01:34 UTCresolved

   Cet incident a été résolu.

3. 24 octobre 2026 à 01:58 UTCpostmortem

   # **Mixpanel RCA: Demandes à** [**decide.mixpanel.com**](http://decide.mixpanel.com) **Échec, 15-21 octobre, 2026** **Résumé** Du 15 octobre 2026 au 21 octobre 2026, les demandes adressées à `decide.mixpanel.com` et `api-decide.mixpanel.com` ont échoué. Cela a affecté les clients qui ont envoyé des demandes de suivi d'événement, de mise à jour de profil ou de drapeau de fonction à ce nom d'hôte, habituellement par l'intermédiaire d'un proxy. Les événements envoyés dans ce domaine pendant cette fenêtre n'ont pas été reçus par Mixpanel et ces données ne peuvent pas être restaurées par Mixpanel. **Traffic envoyé à** `api.mixpanel.com '**,** `api-js.mixpanel.com, ``api-eu.mixpanel.com '** et** `api-in.mixpanel.com ' ** n ' ont pas été affectés.** Le service sur ce nom d'hôte a été involontairement touché pendant que nous supprimions l'infrastructure `/decide`. Les noms d'hôte ont été traités comme faisant partie du paramètre en raison d'une mauvaise compréhension des dépendances du système. Pour éviter cette classe de problèmes, nous ajoutons le suivi du trafic pour les noms d'hôte `decide.mixpanel.com` et `api-decide.mixpanel.com`. Nous exigerons également un trafic zéro confirmé au niveau du nom d'hôte avant que tout nom d'hôte ne soit supprimé. **Nous avons depuis restauré le service sur** `decide.mixpanel.com` . Que s'est-il passé ? Les SDK plus anciens de Mixpanel ont appelé le paramètre `/decide` pour récupérer la configuration pour [**Legacy Automaticly Tracked Mobile Events**](https://docs.mixpanel.com/docs/tracking-methods/sdks/ios#legacy-automatically tracked-events). Nous avons [annoncé le terme de retraite](https://docs.mixpanel.com/changelogs#2026-01-26), et depuis quelque temps `/decide` a renvoyé une réponse `410`. Séparément, `decide.mixpanel.com` et `api-decide.mixpanel.com` ont agi comme alias pour nos noms d'hôte API standard. Par exemple, les événements ingérés `decide.mixpanel.com/track` de la même façon que `api-js.mixpanel.com/track`. Certains clients avaient mis en place des proxies ou des configurations SDK pour envoyer leur trafic vers ces noms d'hôte. Le 15 octobre à 19h40, lors du nettoyage final du paramètre `/decide`, nous avons retiré les enregistrements DNS pour `decide.mixpanel.com` et `api-decide.mixpanel.com` et enlevé les deux noms d'hôte de notre balanceur de charge. Avant de procéder au changement, nous avons confirmé que le trafic vers l'extrémité `/decide` était tombé à zéro. Cependant, notre surveillance a mesuré le trafic par point d'arrêt plutôt que par nom d'hôte. Il n'a donc pas montré que d'autres requêtes, telles que `/track` et `/flags`, atteignaient encore Mixpanel à travers ces noms d'hôte. Dès lors, toutes les requêtes à ce nom d'hôte ont échoué, y compris les paramètres tels que `/track`, `/engage`, `/groups` et `/flags`. * **Événements et profils:** Événements, profils et toute donnée destinée à [Ingestion API endpoints](https://docs.mixpanel.com/reference/ingestion-api) à ces noms d'hôte pendant cette fenêtre n'a jamais atteint Mixpanel, donc nous n'avons pas de copie à restaurer. Si vous avez conservé ces données ailleurs, comme dans les journaux proxy ou votre entrepôt de données, vous pouvez les renvoyer à l'API d'ingestion [/import](https://docs.mixpanel.com/reference/import-events), [/engage,](https://docs.mixpanel.com/reference/profil-set) et [/groups](https://docs.mixpanel.com/reference/group-set-property). * **Drapeaux caractéristiques:** Les requêtes de drapeau de fonctionnalité envoyées à ces noms d'hôte ont échoué. Les SDK ont servi la dernière variante stockée s'il y en avait une, ou autrement la valeur de retour configurée dans votre code. ### Chronologie \(Heure centrale, octobre 2026\) * **15 octobre, 19 h 40 TDC :** La suppression du nom d'hôte est appliquée. Les demandes de `decide.mixpanel.com` et `api-decide.mixpanel.com` commencent à échouer. * **Le 16 octobre, 5 h 22 Nous recevons le premier rapport client. Il est initialement entendu qu ' il s ' agit de la retraite prévue < </décide > > . * **Le 21 octobre, 11 h 42 TDC :** Suite à une augmentation des rapports des clients sur le suivi des défauts de proxies, nous identifions la suppression du nom d'hôte comme la cause. * **Le 21 octobre, à 12 h 26 Nous rétablissons les noms d'hôte. `/decide` reste à la retraite. * **Le 21 octobre, 13 h 51 TDC :** Nous confirmons que le trafic vers les noms d'hôte restaurés s'est rétabli. * **Le 21 octobre, 8 h 34 TDC :** L'incident est résolu. ### **La cause de la mort** 1. Pendant la retraite `/decide`, `decide.mixpanel.com` et `api-decide.mixpanel.com` ont été involontairement supprimés. 2. Ces noms d'hôte avaient été configurés pour accepter tout le trafic API, pas seulement les requêtes `/decide`, et ce comportement était sans papiers. 3. Notre surveillance a permis de suivre le trafic jusqu'au point d'arrêt `/decide` mais pas jusqu'à ces noms d'hôte, de sorte que les vérifications préalables au changement n'ont pas montré que d'autres trafics étaient encore actifs. 4. Étant donné que les noms d ' hôtes et le point de départ à la retraite partagent un nom, les premiers rapports des clients ont été initialement interprétés comme des effets attendus de la retraite annoncée `/décide`. Cette escalade a retardé. Ce que nous changeons * **Surveillance et alerte :** Nous ajoutons le trafic et le taux d'erreur de surveillance et d'alerte pour `decide.mixpanel.com` et `api-decide.mixpanel.com`, de sorte que les défaillances sont détectées automatiquement plutôt que par des rapports clients. * ** Audit du nom d'utilisateur :** Nous vérifions tous les noms d'hôte et alias d'API publics pour des points d'entrée sans papiers similaires, et nous examinerons les nouveaux noms d'hôte et alias avant qu'ils ne soient en direct. Nous suivons également le trafic qui arrive sur tout nom d'hôte inattendu. * **Déménagement des coffres :** Avant tout changement futur à un nom d'hôte public, nous confirmerons le trafic zéro au niveau du nom d'hôte, et nous identifierons et contacterons tous les projets qui l'utilisent encore. * **Communication à la clientèle :** Nous aviserons les clients à l'avance des changements d'infrastructure importants qui affectent les noms d'hôte publics, y compris leur publication sur une ligne temporelle dans notre journal de changement. **Déjà déployé :** * Restauration `decide.mixpanel.com` et `api-decide.mixpanel.com` * `/décide` reste à la retraite Questions communes * ** Mes données ont-elles été touchées?** Seulement si votre SDK ou proxy a envoyé des requêtes à `decide.mixpanel.com` ou `api-decide.mixpanel.com` entre le 15 octobre et le 21 octobre. Les données envoyées pendant cette fenêtre n'ont pas été reçues et ne peuvent pas être restaurées par Mixpanel. Si vous avez conservé une copie de ces données, vous pouvez les renvoyer à Mixpanel en utilisant nos paramètres API d'ingestion tels que `/import` pour les événements. * **Dois-je changer quelque chose?** Non, les domaines fonctionnent encore. Nous vous recommandons d'utiliser `api.mixpanel.com` \(ou `api-eu.mixpanel.com` / `api-in.mixpanel.com` pour la résidence de données UE et Inde\) comme domaine API. * ** Est-ce que** `/decide` revient? C'est pas vrai. Il reste à la retraite comme annoncé, et il est séparé du nom d'hôte `decide.mixpanel.com`. Nous sommes désolés pour la perturbation. Si vous avez des questions sur votre projet, veuillez contacter votre équipe de compte ou Mixpanel Support.

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

1. 8 octobre 2026 à 16:32 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. 8 octobre 2026 à 17:32 UTCidentified

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

3. 8 octobre 2026 à 18:31 UTCidentified

   Nous avons identifié la cause du retard d'ingestion comme un problème en amont avec notre fournisseur de stockage cloud, Google Cloud, impactant un sous-ensemble de projets américains. Google a confirmé cela comme une question hautement prioritaire à leur fin, mais n'a pas encore fourni une ETA. Nous avons déployé des mesures d'atténuation pour assurer un rétablissement en douceur une fois qu'il s'est dégagé. Aucun événement n'est perdu. Il s'agit strictement d'un délai d'ingestion, toutes les données touchées continueront d'être traitées une fois le problème résolu.

4. 8 octobre 2026 à 19:30 UTCmonitoring

   Nos mesures montrent que l'ingestion est rattrapée et ne connaît plus de retard. Google n'a pas encore confirmé la résolution de la question en amont sous-jacente à leur fin, donc nous continuons à surveiller de près en cas de récidive.

5. 8 octobre 2026 à 21:30 UTCmonitoring

   Aucun changement depuis notre dernière mise à jour, nous continuons d'observer aucun retard d'ingestion active à notre fin, et tous les systèmes restent sains. Nous continuons de surveiller de près.

6. 8 octobre 2026 à 22:30 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

7. 8 octobre 2026 à 23:30 UTCmonitoring

   Les systèmes sont demeurés stables sans récurrence du délai d'ingestion. Nous gardons un œil sur les choses pendant que nous attendons la confirmation finale de notre fournisseur en amont.

8. 9 octobre 2026 à 00:22 UTCresolved

   Cet incident a été résolu. Le problème en amont avec notre fournisseur de stockage en nuage a été corrigé, et notre pipeline d'ingestion a fonctionné normalement sans retard actif. Aucun événement n'a été perdu pendant cet incident, toutes les données touchées ont été entièrement traitées. Merci de votre patience tout au long de cet incident.

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

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.

5. 8 septembre 2026 à 18:25 UTCpostmortem

   # Mixpanel RCA: Perturbation temporaire du service de requête pour les projets américains 26 août 2026 # Résumé Entre environ **2:02 PM et 3:19 PM PT le 26 août 2026**, des projets dans la région des États-Unis ont connu des défaillances en chargeant des rapports et en exécutant des requêtes via l'interface utilisateur Mixpanel et l'API Query. Pendant cette fenêtre, certaines requêtes dans la région ont échoué ou retourné des erreurs. **Aucune donnée client n'a été perdue et l'ingestion n'a pas été affectée.** Tous les événements ont continué d'être recueillis et stockés normalement tout au long de l'incident; une fois le service de requête rétabli, tous les rapports reflétaient des données complètes et exactes, sans intervention du client. La cause a été identifiée comme un outil interne récemment déployé pour le replay de requêtes diagnostiques, une capacité que nos ingénieurs utilisent pour ré-exécuter des copies de requêtes passées pour déboguer les performances, qui a écrit de grandes quantités de données inattendues sur les disques de nos serveurs de requêtes, consommant la capacité de stockage dont les serveurs ont besoin pour fonctionner. Lorsque ces disques ont été remplis, les serveurs touchés se sont retirés du service. Le service a été rétabli, les serveurs touchés ont été ramenés en ligne et l'outillage interne a été désactivé. Les correctifs ci-dessous ajoutent des garanties de stockage pour supprimer la capacité de l'outillage interne de consommer des ressources sur les serveurs de requêtes, et sont conçus pour empêcher cette classe d'échecs de se reproduire à l'avenir. Que s'est-il passé ? Le moteur de requête de Mixpanel fonctionne sur une flotte de serveurs qui utilisent chacun un ensemble de volumes de stockage locaux pour mettre en cache les données nécessaires pour répondre rapidement aux requêtes. Nos ingénieurs utilisent séparément l'outil de rejouage des requêtes diagnostiques, une capacité que nos ingénieurs utilisent pour reproduire et déboguer les performances des requêtes. Lors de l'application de l'outil de rejouage de la requête diagnostique à une requête grande et complexe, un bug logiciel a causé les captures de rejouage de la requête à fan dehors dans toute la flotte au lieu de rester confiné à un seul serveur. En outre, il a causé beaucoup plus de données que prévu pour être sauvegardés sans expulsion en temps utile sur un seul serveur. Deux facteurs ont ensuite élargi l'impact de la question : * Un seul volume de stockage complet a mis un serveur hors service. Chaque serveur traite son cache comme malsain si l'un de ses volumes de stockage dépasse un seuil d'utilisation, même lorsque tous les autres volumes sont sains. Les données de replay ont été écrites à un volume spécifique sur chaque serveur, de sorte que les serveurs de toute la région ont échoué leurs contrôles de santé presque simultanément. * Les limites de nettoyage ne tenaient pas compte de la taille des données. La sauvegarde limitant le replay des données sur le disque compte les éléments au niveau de l'application plutôt que les octets au niveau du système de fichiers, de sorte qu'un petit nombre de captures inattendues de grande taille ont passé le contrôle tout en consommant la plupart de la capacité de volume. Ensemble, ils ont permis un seul workflow de débogage qui a normalement une empreinte négligeable pour interrompre la requête de production dans toute la région américaine. # Chronologie \(Heure du Pacifique, 26 août 2026\) * ** 2:00 PM** — La première capture de replay diagnostique surdimensionnée a été écrite; les volumes de stockage ont commencé à atteindre leur capacité et le taux de succès des requêtes a commencé à baisser peu après. * ** 2:17** — L'alerte automatisée a mis en page l'ingénieur de garde; l'enquête a commencé immédiatement et d'autres ingénieurs ont été engagés. * **2:39 PM** — L'incident de la page d'état a été affiché; bannière in-app affichée à 14:40 PM. * **2:53 PM** — Cause racine identifiée; les efforts de récupération ont commencé sur le premier groupe de serveur affecté. * **3:19** — Service de requêtes restauré pour la grande majorité du trafic; le groupe serveur final a complètement récupéré à 15:27 PM. * **3h45** — L'incident est réglé après une période d'observation stable. Le rejouage diagnostique qui a déclenché le problème a été complètement désactivé le soir même. Cause profonde 1. **Un bug logiciel dans notre replay de requête a causé des écritures non liées au stockage de production.** Une capacité récemment déployée pour reproduire des requêtes a mal géré une classe particulière de requêtes complexes, ce qui a entraîné des captures à se propager à chaque serveur de requêtes dans la région et à écrire beaucoup plus de données aux volumes touchés que le design supposé. 2. **Rejouer les fichiers consommés capacité de disque sur laquelle la requête sert dépend.** L'outil de replay a écrit ses fichiers sur les disques locaux des serveurs de requêtes, de sorte que la capacité de stockage épuisée des données de replay les serveurs doivent répondre aux requêtes. 3. **Les gardes n'ont tenu compte que partiellement du comportement.** La politique de nettoyage pour le rejouage des données diagnostiques a limité le nombre d'éléments sur le disque, mais pas leur taille totale, donc il n'a pas engagé. L'alerte sur les volumes de stockage a marqué la croissance mais n'a pas été augmentée comme critique sur une base par serveur, ce qui a retardé la détection jusqu'à ce que les défaillances de la requête commencent. Ce que nous changeons L'état final que nous construisons vers : requête de diagnostic interne rejouer les données stockées dans le stockage d'objets dédié, ne plaçant aucune charge sur les serveurs de requête de production. Déjà déployé : * ** Désactivé l'outil interne** qui a causé l'incident, et corrigé le problème sous-jacent de sorte que les captures de diagnostic sont limitées à un seul serveur et la classe de requête spécifique est traitée correctement. * **Il a documenté la procédure de récupération ciblée** utilisée lors de l'incident, c'est-à-dire que le volume de stockage touché n'a pas été remis à zéro, mais plutôt que de redémarrer des groupes de serveurs complets, dans nos runbooks opérationnels, raccourcissant ainsi le temps de récupération si une capacité quelconque de volume s'épuise à l'avenir. En cours: * ** Limites basées sur la taille du système de fichiers sur les données de rejouage diagnostique**, plafonnant les octets totaux sur le disque plutôt que le nombre d'articles, de sorte que les captures surdimensionnées sont rejetées ou expulsées avant qu'elles puissent affecter la capacité du volume. * **Alerte de stockage plus stricte**, augmentation de la saturation en volume par serveur aussi critique qu'elle ne peut affecter les contrôles de santé des requêtes. * **Déplacer les données de la requête vers le stockage d'objets dédié**, donc il ne consomme aucune ressource sur les serveurs de requête de production. # Questions communes * **Est-ce que des données ont été perdues?** Non. L'ingestion de données n'a pas été affectée tout au long de l'incident : les événements ont continué à être recueillis, en attente et entreposés normalement. Seule la capacité de requête a été interrompue. Une fois le service rétabli, tous les rapports contenaient des données complètes. * **Les rapports, les tableaux de bord ou les paramètres du projet ont-ils été enregistrés?** C'est pas vrai. L'incident n'a affecté que l'exécution de la requête. Rien dans votre projet n'a changé. * **Pourquoi a-t-il affecté plusieurs projets américains en même temps?** Les données de rejouage de diagnostic surdimensionnées écrites sur les disques de chaque serveur de requête à peu près en même temps, et chaque serveur se supprime du service quand un volume remplit. Empêcher l'outillage interne de consommer le stockage des serveurs de requêtes est une partie essentielle de nos travaux d'assainissement. * **Comment cela est-il empêché d'aller de l'avant?** La question de l'outillage est résolue et l'outillage reste désactivé jusqu'à ce que des limites fondées sur la taille soient en place. L'alerte de stockage est resserrée de sorte que la saturation est capturée avant qu'elle affecte le service de requête. Structurellement, nous déplaçons entièrement les données diagnostiques des serveurs de requêtes de production, de sorte que le débogage interne ne consommera aucun stockage sur les serveurs responsables du traitement des requêtes. Nous nous excusons pour la perturbation et pour le temps que les rapports n'étaient pas disponibles. Veuillez contacter votre équipe de compte ou votre support pour toute question.

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.