Historial de interrupciones de Mixpanel

1. 21 de octubre de 2026 a las 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 de octubre de 2026 a las 20:15 UTCresolved

   This incident has been resolved.

1. 21 de octubre de 2026 a las 22:28 UTCmonitoring

   Hemos recibido informes que solicitan decidir.mixpanel.com está fallando. Cualquier tráfico enviado a través de decide.mixpanel.com puede ser afectado, incluyendo banderas de características y seguimiento de eventos. Para restaurar el servicio ahora, solicite puntos api.mixpanel.com (US), api-eu.mixpanel.com (EU), o api-in.mixpanel.com (IN), dependiendo de la Residencia de Datos de su proyecto. Hemos lanzado una mitigación y estamos monitoreando los resultados. Estamos viendo el tráfico restaurado. Publicaremos actualizaciones de progreso en nuestra página de estado. Si tiene alguna pregunta, por favor contacte con soporte.

2. 22 de octubre de 2026 a las 1:34 UTCresolved

   Este incidente ha sido resuelto.

3. 24 de octubre de 2026 a las 1:58 UTCpostmortem

   **Mixpanel RCA: Solicitudes a** [**decide.mixpanel.com**](http://decide.mixpanel.com) **Failed, October 15–21, 2026** #### **Summary** Del 15 de octubre de 2026 al 21 de octubre de 2026, las solicitudes enviadas a `decide.mixpanel.com` y `api-decide.mixpanel.com` fracasaron. Estos clientes afectados que enviaron seguimiento de eventos, actualizaciones de perfiles o solicitudes de bandera de características a este nombre de host, generalmente a través de un proxy. Los eventos enviados a este dominio durante esta ventana no fueron recibidos por Mixpanel y estos datos no pueden ser restaurados por Mixpanel. **Traffic sent to** `api.mixpanel.com`**, ** `api-js.mixpanel.com,` `api-eu.mixpanel.com`**, and** `api-in.mixpanel.com **were not affected.** El servicio en este nombre de host fue involuntariamente impactado mientras estábamos eliminando la infraestructura de punto final de `/decide`. The hostnames were treated as part of the endpoint due to an incorrect understanding of system dependentncies. Para evitar esta clase de problema, estamos añadiendo monitoreo de tráfico para los nombres de anfitriones `decide.mixpanel.com` y `api-decide.mixpanel.com. También necesitaremos tráfico cero confirmado a nivel de hostname antes de eliminar cualquier nombre de host. **Desde entonces hemos restaurado el servicio en ** `decide.mixpanel.com`. Lo que pasó Los SDK de Older Mixpanel llamaron el punto final de `/decide` para buscar la configuración de [**Legacy Automatically Tracked Mobile Events**](https://docs.mixpanel.com/docs/tracking-methods/sdks/ios#legacy-automatically-tracked-events). We [announced the endpoint’s removal](https://docs.mixpanel.com/changelogs#2026-01-26), and for some time `/decide` has returned a `410` response. Por separado, `decide.mixpanel.com` y `api-decide.mixpanel.com` actuaron como alias para nuestros nombres de host API estándar. Por ejemplo, `decide.mixpanel.com/track` ingested events the same way `api-js.mixpanel.com/track` does. Algunos clientes habían establecido proxies o configuraciones SDK para enviar su tráfico a estos nombres de host. El 15 de octubre a las 7:40 PM CDT, durante la limpieza final del punto final del `/decide`, eliminamos los registros DNS para `decide.mixpanel.com` y `api-decide.mixpanel.com` y retiramos ambos nombres de host de nuestro balanceador de carga. Antes de hacer el cambio, confirmamos que el tráfico al punto final de `/decide` había caído a cero. Sin embargo, nuestro monitoreo midió el tráfico por punto final en lugar de por nombre de host. Por consiguiente, no mostró que otras solicitudes, como " vía " y " , siguieran llegando a Mixpanel a través de estos nombres de acogida. A partir de entonces, todas las solicitudes a este nombre de anfitrión fracasaron, incluidos los puntos finales como `/track`, `/engage`, `/groups`, y `/flags`. * **Eventos y Perfiles:** Eventos, Perfiles y cualquier dato destinado a [Ingestion API endpoints](https://docs.mixpanel.com/reference/ingestion-api) a estos nombres de host durante esta ventana nunca llegaron a Mixpanel, por lo que no tenemos una copia para restaurar. Si retenía estos datos en otros lugares, como en los registros proxy o su almacén de datos, puede volver a enviarlos a la API de Ingestión [/import](https://docs.mixpanel.com/reference/import-events), [/engage,](https://docs.mixpanel.com/reference/profile-set) y [/docpanty] * ** banderas de la naturaleza:** Las solicitudes de bandera de características enviadas a estos nombres de anfitriones fracasaron. Los SDKs sirvieron la última variante almacenada si existió, o de otro modo el valor de descomposición configurado en su código. ### Timeline \(Tiempo Central, Octubre 2026\) * ** 15 de octubre, 7:40 PM CDT:** Se aplica la eliminación del nombre de host. Solicitudes de `decide.mixpanel.com` y `api-decide.mixpanel.com` comienzan a fallar. * ** 16 de octubre, 5:22 AM CDT:** Recibimos el primer informe del cliente. Inicialmente se entiende que está relacionado con la jubilación prevista de `/decide ' . * ** 21 de octubre de 11:42 AM CDT:** Tras un aumento de los informes de los clientes sobre el fallo de seguimiento de los proxies, identificamos la eliminación del nombre de host como la causa. * ** 21 de octubre de 12:26 PM CDT:** Restituimos los nombres de host. Queda retirado. * ** 21 de octubre de 1:51 PM CDT:** Confirmamos que el tráfico a los nombres de host restaurados se ha recuperado. * ** 21 de octubre, 8:34 PM CDT:** El incidente está resuelto. #### **Causa principal** 1. Durante la jubilación `/decide ' , `decide.mixpanel.com ' y `api-decide.mixpanel.com` fueron eliminados sin querer. 2. These hostnames had been configured to accept all API traffic, not only `/decide` requests, and this behaviour was undocumented. 3. Nuestra vigilancia rastreó el tráfico hasta el punto final del `/decide ' pero no a estos nombres de anfitriones, por lo que los controles previos al cambio no mostraron que el otro tráfico todavía estaba activo. 4. Dado que los nombres de los anfitriones y el punto final retirado comparten un nombre, los informes iniciales de los clientes se interpretaron inicialmente como efectos esperados de la jubilación anunciada. Esta escalada retardada. Lo que estamos cambiando * **Monitoring and alerting:** Estamos agregando monitorización y alerta de tráfico y tasa de error para `decide.mixpanel.com` y `api-decide.mixpanel.com`, por lo que se detectan fallos automáticamente en lugar de a través de informes de clientes. * **Audición del nombre de pila:** Estamos auditando todos los nombres de host API públicos y alias de routing para puntos de entrada similares indocumentados, y vamos a revisar nuevos nombres de host y alias antes de que vayan en directo. También estamos rastreando el tráfico que llega a cualquier nombre de host inesperado. * ** Eliminación de la separación:** Antes de cualquier cambio futuro a un nombre de host público, confirmaremos el tráfico cero a nivel de hostname, y identificaremos y contactaremos cualquier proyecto que aún lo use. * **Comunicación cliente:** Daremos a los clientes aviso anticipado de los cambios de infraestructura material que afectan a los nombres de los anfitriones públicos, incluyendo publicarlos en una línea de tiempo en nuestro cambio. **Ya desplegados** * Restored `decide.mixpanel.com` and `api-decide.mixpanel.com` * `/decide` remains withdraw ################################################################################################################################################################################################################################################################ * ** ¿Mis datos fueron afectados?** Sólo si su SDK o proxy envió peticiones a `decide.mixpanel.com` o `api-decide.mixpanel.com` entre el 15 y el 21 de octubre. Los datos enviados allí durante esa ventana no fueron recibidos y no pueden ser restaurados por Mixpanel. Si retuvo una copia de esos datos, puede volver a enviarla a Mixpanel utilizando nuestros puntos finales de la API de Ingestión, como `/import` para eventos. ¿Necesito cambiar algo? No, los dominios funcionan de nuevo. Recomendamos utilizar `api.mixpanel.com` \(o `api-eu.mixpanel.com` / `api-in.mixpanel.com` para la residencia de datos de la UE y la India\) como su dominio API. * **¿Está regresando? No. Queda retirado como se anunció, y está separado del nombre de host `decide.mixpanel.com`. Lo sentimos por la interrupción. Si tiene preguntas sobre su proyecto, por favor contacte con su equipo de cuenta o Soporte Mixpanel.

Traducido automáticamente desde la actualización oficial del incidente.

1. 8 de octubre de 2026 a las 16:32 UTCinvestigating

   Actualmente estamos experimentando retrasos en nuestro oleoducto de ingestión de datos, que está afectando datos en tiempo real para proyectos inscritos en los EE.UU., dando lugar a demoras para un subconjunto de proyectos. Mientras no se pierden datos, nuestro equipo de ingeniería está investigando activamente la materia y trabajando para restaurar la funcionalidad en tiempo real lo más rápido posible. Apreciamos su paciencia durante este tiempo. Si tiene alguna pregunta, por favor contacte con soporte.

2. 8 de octubre de 2026 a las 17:32 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 8 de octubre de 2026 a las 18:31 UTCidentified

   Hemos identificado la causa de la demora de la ingestión como un problema de arriba con nuestro proveedor de almacenamiento en la nube, Google Cloud, impactando un subconjunto de proyectos estadounidenses. Google ha confirmado esto como un problema de alta prioridad en su extremo, pero no ha proporcionado un ETA todavía. Hemos implementado mitigacións para asegurar una recuperación suave una vez que se despeja. No se están perdiendo eventos. Esto es estrictamente un retraso en la ingestión, todos los datos afectados seguirán siendo reprocesados una vez resuelto el problema.

4. 8 de octubre de 2026 a las 19:30 UTCmonitoring

   Nuestras métricas muestran que la ingestión está atrapada y ya no experimenta retraso. Google todavía no ha confirmado la resolución de la cuestión subyacente en su extremo, por lo que seguimos monitoreando de cerca en caso de recurrencia.

5. 8 de octubre de 2026 a las 21:30 UTCmonitoring

   Sin cambios desde nuestra última actualización, seguimos observando ningún retraso activo en la ingestión de nuestro fin, y todos los sistemas siguen siendo saludables. Continuamos monitoreando de cerca.

6. 8 de octubre de 2026 a las 22:30 UTCmonitoring

   Continuamos monitoreando cualquier otro problema.

7. 8 de octubre de 2026 a las 23:30 UTCmonitoring

   Los sistemas han permanecido estables sin que se repita el retraso de la ingestión. Estamos vigilando las cosas mientras esperamos la confirmación final de nuestro proveedor de corriente.

8. 9 de octubre de 2026 a las 0:22 UTCresolved

   Este incidente ha sido resuelto. El problema de arriba con nuestro proveedor de almacenamiento en la nube se ha fijado, y nuestro oleoducto de ingestión ha estado operando normalmente sin demoras activas. No se perdieron eventos durante todo este incidente, todos los datos afectados fueron totalmente reprocesados. Gracias por su paciencia durante todo este incidente.

Traducido automáticamente desde la actualización oficial del incidente.

1. 26 de agosto de 2026 a las 21:39 UTCinvestigating

   Mixpanel está experimentando el rendimiento de Query API degradado, dando como resultado respuestas HTTP 500 al consultar informes para proyectos con la Residencia de Datos de EE.UU. Los proyectos con la UE e IN Data Residency siguen sin afectarse. Apreciamos su paciencia mientras nuestros ingenieros trabajan para restaurar la funcionalidad normal. Publicaremos actualizaciones de progreso en nuestra página de estado. Si tiene alguna pregunta, por favor contacte con soporte.

2. 26 de agosto de 2026 a las 22:11 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 26 de agosto de 2026 a las 22:28 UTCmonitoring

   Se ha implementado una solución, y estamos viendo mejores tasas de éxito para la API de consulta. Seguiremos vigilando para asegurar la estabilidad.

4. 26 de agosto de 2026 a las 22:45 UTCresolved

   Este incidente ha sido resuelto.

5. 8 de septiembre de 2026 a las 18:25 UTCpostmortem

   # Mixpanel RCA: Interrupción de Servicio de Consulta Temporal para Proyectos de Estados Unidos 26 de agosto de 2026 # Resumen Entre aproximadamente **2:02 PM y 3:19 PM PT el 26 de agosto de 2026**, los proyectos en la región de Estados Unidos experimentaron fracasos cargando informes y realizando consultas a través de la UI Mixpanel y la API Query. Durante esta ventana, algunas consultas en la región fallaron o devolvieron errores. **No se perdieron datos de clientes, y la ingestión de datos no fue afectada.** Todos los eventos continuaron siendo recogidos y almacenados normalmente durante todo el incidente; una vez restaurado el servicio de consulta, todos los informes reflejaron datos completos y precisos sin necesidad de acción del cliente. La causa fue identificada como una herramienta interna recientemente implementada para la repetición de consultas diagnósticas, una capacidad que nuestros ingenieros utilizan para re-corrir copias de consultas pasadas para depurar el rendimiento, que imprevisto escribió grandes cantidades de datos a los discos de nuestros servidores de consultas, consumiendo capacidad de almacenamiento que los servidores necesitan operar. Cuando esos discos se llenaron, los servidores afectados se sacaron del servicio. El servicio fue restaurado, los servidores afectados fueron devueltos en línea, y la herramienta interna fue deshabilitada. Las remediaciones a continuación añaden salvaguardias de almacenamiento para eliminar la capacidad de herramientas internas de consumir recursos en servidores de consulta, y están diseñadas para evitar que esta clase de fracaso vuelva a suceder en el futuro. Lo que pasó El motor de búsqueda de Mixpanel funciona en una flota de servidores que cada uno utiliza un conjunto de volúmenes de almacenamiento local para cachear los datos necesarios para responder las consultas rápidamente. Por separado, nuestros ingenieros utilizan herramientas de replay de consultas diagnósticas, una capacidad que nuestros ingenieros usan para reproducir y depurar el rendimiento de la consulta. Si bien la aplicación de la replay de la consulta diagnóstica a una consulta grande y compleja, un error de software causó que las capturas de reproducción de la consulta se fanearan a través de toda la flota en lugar de permanecer limitado a un solo servidor. Además, causó mucho más datos de los que se pretendía guardar sin el desalojo oportuno en un solo servidor. Dos factores ampliaron el impacto de la cuestión: * Un solo volumen de almacenamiento completo tomó un servidor completamente fuera de servicio. Cada servidor trata su caché como poco saludable si alguno de sus volúmenes de almacenamiento cruza un umbral de uso, incluso cuando todos los demás volúmenes son saludables. Los datos de reproducción fueron escritos a un volumen específico en cada servidor, por lo que los servidores de toda la región fallaron sus cheques de salud casi simultáneamente. * Los límites de limpieza no contabilizaron el tamaño de los datos. La salvaguardia que limita los datos de repetición en los elementos contados en disco a nivel de aplicación en lugar de bytes a nivel del sistema de archivos, por lo que un pequeño número de capturas inesperadamente grandes pasaron el cheque mientras que consume la mayor parte de la capacidad del volumen. Juntos, esto permitió un único flujo de trabajo depurante que normalmente tiene una huella insignificante para interrumpir la consulta de producción que sirve en toda la región estadounidense. # Timeline \(Pacific Time, August 26, 2026\) * **2:00 PM** — Se escribió la primera captura de reproducción de diagnóstico sobredimensionada; los volúmenes de almacenamiento comenzaron a alcanzar su capacidad y la tasa de éxito de consulta comenzó a caer poco después. * **2:17 PM** — El aviso automatizado llamó al ingeniero de guardia; la investigación comenzó inmediatamente y se contrataron otros ingenieros. * **2:39 PM** — incidente de la página del estado publicado; banner de la aplicación mostrado a las 2:40 PM. * **2:53 PM** — Causa raíz identificada; los esfuerzos de recuperación comenzaron en el primer grupo servidor afectado. * **3:19 PM** — Servicio de consulta restaurado para la gran mayoría de tráfico; el grupo final del servidor se recuperó completamente a las 3:27 PM. * **3:45 PM** — El incidente resuelto después de un período de observación estable. La herramienta de repetición de diagnóstico que provocó el problema fue completamente deshabilitado la misma noche. # Root cause 1. **Un error de software en nuestra búsqueda replay tooling causó escritos sin límites al almacenamiento de producción.** Una capacidad recientemente desplegada para reproducir las consultas malinterpretó una clase particular de consulta compleja, causando capturas que se propagan a cada servidor de consulta en la región y para escribir más datos a los volúmenes afectados que el diseño asumido. 2. **Replay archivos consumidos capacidad de disco de la query porción depende.** El replay tooling escribió sus archivos a los discos locales de los servidores de consulta, por lo que los datos de replayaway agotaron la capacidad de almacenamiento que los servidores necesitan para responder preguntas. 3. **Las salvaguardias sólo representaron parcialmente el comportamiento.** La política de limpieza de los datos de repetición de diagnóstico limitó el número de elementos en disco, pero no su tamaño total, por lo que no se involucró. Al alertar sobre los volúmenes de almacenamiento se registró el crecimiento, pero no se intensificó como crítico sobre una base por servicio, lo que atrasó la detección hasta que se iniciaron fallos de consulta. Lo que estamos cambiando El estado final que estamos construyendo hacia: datos de reproducción de consultas de diagnóstico interno almacenados en almacenamiento de objetos dedicados, sin carga en servidores de búsqueda de producción. Ya desplegado: * **Deshabilitado la herramienta interna** que causó el incidente, y remediado el problema subyacente por lo que las capturas de diagnóstico se limitan a un solo servidor y la clase de consulta específica se maneja correctamente. * **Documentó el procedimiento de recuperación selectiva** utilizado durante el incidente, es decir, despejar sólo el volumen de almacenamiento afectado en lugar de reiniciar grupos de servidores completos, en nuestros registros operativos, acortando el tiempo de recuperación si la capacidad de cualquier volumen se agota en el futuro. En curso: * ** Límites a nivel de sistema, basados en tamaños sobre los datos de repetición de diagnóstico**, capturando los bytes totales en el disco en lugar de los recuentos de elementos, por lo que las capturas de tamaño superior son rechazadas o desalojadas antes de que puedan afectar la capacidad del volumen. * **Aviso de almacenamiento más estricto**, escalando la saturación de volumen por servidor como crítica antes de que pueda afectar las consultas de salud. * **Moving query replay data to dedicated object storage,** so it consume no resources on production query servers. # Common questions * ** ¿Se perdieron datos?** No. La ingestión de datos no se vio afectada durante todo el incidente: los eventos siguieron siendo recogidos, consultados y almacenados normalmente. Sólo se interrumpió la capacidad de consulta. Una vez restaurado el servicio, todos los informes reflejan datos completos. * **¿Fueron afectados los informes guardados, los paneles o la configuración del proyecto?** No. El incidente solo afectó la ejecución de la consulta. Nada almacenado en su proyecto cambió. * **¿Por qué afectó a varios proyectos estadounidenses a la vez?** Los datos de repetición de diagnóstico sobredimensionados escritos a los discos de cada servidor de consultas casi al mismo tiempo, y cada servidor se retira del servicio cuando un volumen se llena. Evitar el uso de herramientas internas del almacenamiento del servicio de consultas es una parte fundamental de nuestro trabajo de rehabilitación. * **¿Cómo se impide esto avanzar?** La cuestión de la herramienta se resuelve y la herramienta sigue siendo desactivada hasta que existan límites basados en el tamaño. La alerta de almacenamiento se está endureciendo así que la saturación es atrapada antes de que afecta el servicio de consulta. Structuralmente, estamos moviendo datos de diagnóstico de servidores de búsqueda de producción enteramente, por lo que los datos de depuración interna no consumirán almacenamiento en los servidores responsables del procesamiento de consultas. Nos disculpamos por la interrupción y por los informes de tiempo no estaban disponibles. Por favor, contacte a través de su equipo de cuenta o apoyo con cualquier pregunta.

Traducido automáticamente desde la actualización oficial del incidente.

1. 19 de agosto de 2026 a las 23:20 UTCidentified

   Actualmente estamos experimentando problemas con las propiedades del evento populando en los menús desplegables. Apreciamos su paciencia mientras nuestros ingenieros trabajan para restaurar la funcionalidad. Si tiene alguna pregunta, póngase en contacto con [email protected]

2. 20 de agosto de 2026 a las 1:04 UTCidentified

   Seguimos trabajando en una solución para esta cuestión.

3. 20 de agosto de 2026 a las 2:52 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

4. 20 de agosto de 2026 a las 3:05 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 6 de agosto de 2026 a las 7:19 UTCinvestigating

   We are aware that the Get-Report tool in the Mixpanel MCP server is currently failing when called with skip_results: false. Report metadata is unaffected. We are investigating the issue and will provide updates as we have them.

2. 6 de agosto de 2026 a las 8:39 UTCidentified

   The issue has been identified and fix is being implemented.

3. 6 de agosto de 2026 a las 9: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 de agosto de 2026 a las 13:32 UTCresolved

   This incident has been resolved.

1. 22 de julio de 2026 a las 8:03 UTCinvestigating

   Actualmente estamos experimentando problemas con el agente Mixpanel dentro de la aplicación web. Nuestro equipo de ingeniería ha sido alertado y está investigando el problema y trabajando para restaurar su funcionalidad. Apreciamos su paciencia mientras trabajamos para resolver este asunto. Si tiene alguna pregunta, por favor contacte con soporte.

2. 22 de julio de 2026 a las 9:52 UTCinvestigating

   el equipo sigue investigando la cuestión y los próximos pasos. Gracias por su paciencia.

3. 22 de julio de 2026 a las 10:55 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

4. 22 de julio de 2026 a las 14:47 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 11 de julio de 2026 a las 7:53 UTCinvestigating

   Actualmente estamos experimentando retrasos en nuestro oleoducto de ingestión de datos, que está afectando datos en tiempo real para proyectos inscritos en los EE.UU., dando lugar a demoras para un subconjunto de proyectos. Mientras no se pierden datos, nuestro equipo de ingeniería está investigando activamente la materia y trabajando para restaurar la funcionalidad en tiempo real lo más rápido posible. Apreciamos su paciencia durante este tiempo. Si tiene alguna pregunta, por favor contacte con soporte.

2. 11 de julio de 2026 a las 9:17 UTCinvestigating

   Seguimos investigando esta cuestión.

3. 11 de julio de 2026 a las 10:15 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

4. 11 de julio de 2026 a las 12:54 UTCidentified

   Seguimos trabajando en una solución para esta cuestión.

5. 11 de julio de 2026 a las 14:25 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

6. 11 de julio de 2026 a las 15:54 UTCresolved

   Este incidente ha sido resuelto.

7. 16 de julio de 2026 a las 23:47 UTCpostmortem

   # Resumen Entre aproximadamente **11:35 PM PT los días 10 y 7:19 AM PT el 11 de julio de 2026**, la ingestión de datos para proyectos de Mixpanel en la región de Estados Unidos corrió hasta ~2 horas. Durante esta ventana, los informes y los paneles mostraron temporalmente datos incompletos; los intervalos de tiempo recientes podrían aparecer como gotas agudas y artificiales en métricas como usuarios activos o ingresos. **No se perdieron datos.** Todos los eventos fueron consultados duramente y procesados en su totalidad una vez que el atraso se despejó; las métricas regresaron a valores exactos por su cuenta, sin necesidad de acción del cliente. La causa se originó en nuestros controles de ingestión: para un pequeño número de proyectos de muy alto volumen, las tasas de ingestión que permitimos se habían desviado de la alineación con la capacidad prevista para esos proyectos. Por lo tanto, las grandes importaciones históricas —el uso totalmente legítimo de la plataforma— fueron admitidas más rápido de lo que su infraestructura podría absorber, y dos propiedades de nuestro oleoducto convirtieron esa sobrecarga localizada en un retraso en toda la región. Las fijaciones debajo realinean esos controles para que cualquier importación, de cualquier tamaño, se mantenga automáticamente dentro de límites seguros. Lo que pasó El gasoducto de ingestión de Mixpanel se endurece y tiene múltiples componentes: los datos de cada proyecto se distribuyen a través de un conjunto de particiones tamaño para su volumen esperado, y para el rendimiento, los eventos de muchos clientes se procesan juntos en lotes. Este diseño ofrece una alta eficiencia, pero depende de un invariante: la tasa a la que admitimos que el tráfico de un proyecto debe coincidir con la capacidad prevista para él. Cuando ese invariante sostiene, incluso las importaciones muy grandes se absorben sin problemas. Aquí, no aguantó. Un pequeño número de importaciones históricas de datos muy grandes se extendieron a proyectos cuyas tasas de ingestión permitidas, con el tiempo, habían aumentado mucho más allá de su capacidad de partición prevista. El volumen de exceso se concentró en particiones específicas como ** puntos calientes**, saturando la porción de la flota de streaming que los sirve. Dos factores ampliaron el impacto: * **El procesamiento de varios componentes amplifica los puntos calientes.** Debido a que los eventos de muchos clientes viajan juntos en lotes, lentitud y fallas en las particiones sobrecargadas retrasaron los eventos de clientes no relacionados compartiendo esos lotes. * **El aumento automático fue ineficaz.** La capacidad de adición no puede disolver un punto caliente de este tipo, porque las particiones sobrecargadas permanecen sujetas a la misma infraestructura, y un límite de capacidad en un componente de nuestra infraestructura de streaming impidió que la capacidad agregada entrara en vigor. Juntos, estos convirtieron lo que debería haber sido una breve y auto-sanación desaceleración en un retraso de varias horas que requiere intervención manual. # Timeline \(Pacific Time, July 10–11\) * **11:35 PM** — El alertado automatizado detectó el atraso de la ingestión; el ingeniero de guardia contratado inmediatamente. * **12:49 AM** — incidente de la página de estado publicado; impacto abarcado sólo a la región de Estados Unidos. * **1:23 AM** Se detuvo la mayor importación de contribución. * **1:55–6:48 AM** — Mitigaciones progresivas: surgieron fuentes de tráfico adicionales, ciertos datos retrocedidos diferidos por el acuerdo del cliente, el aislamiento de falla habilitado en el oleoducto y los nodos de infraestructura afectados reemplazados. * **7:19 AM** — Backlog totalmente procesado; todos los proyectos actuales. La página de estado se trasladó a la vigilancia, después de un período de observación estable. # Root cause 1. ** Los límites de la tasa de ingestión se ajustan erróneamente a la capacidad prevista**. Para los proyectos de conducción, las tarifas admitidas por nuestra plataforma habían aumentado de forma gradual con la infraestructura suministrada para ellos, por lo que las importaciones legítimas de alto volumen se dejaron entrar más rápido de lo que sus particiones podían absorber. Esta es la causa raíz sistémica. Las propias importaciones eran un uso legítimo de la plataforma. 2. **El procesamiento de varias piezas amplifica la sobrecarga.** Las fallas en las particiones sobrecargadas retrasaron los eventos de clientes no relacionados compartiendo los mismos lotes de procesamiento, difundiendo un problema localizado en toda la plataforma. 3. **Traffic to the overloaded particiones could not be redistributed.** La asignación de partición a servidor en la capa de streaming no era de carga, por lo que los puntos calientes se quedaron clavados a los mismos servidores independientemente del tamaño de la flota — la capacidad total era suficiente, pero no se podía llevar a cabo. Un límite de escalado en un componente de nuestra infraestructura de streaming lo agravó impidiendo la ampliación de la capacidad de adición, que retrasaron el diagnóstico hasta que los ingenieros intervinieron manualmente. Lo que estamos cambiando El estado final que estamos construyendo hacia: **Todos los límites de ingestión del proyecto coinciden automáticamente con su capacidad prevista, de modo que las importaciones de cualquier tamaño, incluyendo los backfills históricos completos y los sincronías de almacén de datos, pueden funcionar sin coordinación anticipada, y el volumen de un proyecto se impide afectar la frescura de datos de otro.**. Ya desplegados, mejorando nuestro manejo de la ingestión: * **Mejorado manejo de puntos calientes.** La distribución de tráfico en la capa de streaming es ahora de carga, la difusión de carga concentrada más uniformemente a través de la flota, y los elementos de problemas individuales se retratan por separado en lugar de mantener el resto de su lote — reduciendo, aunque no eliminando, el impacto que una sobrecarga localizada puede tener en el tráfico no relacionado. * **Reprovisionó las cargas de trabajo de mayor volumen** sobre infraestructuras de tamaño adecuado, priorizadas por riesgo. Ya desplegado —cambiando cómo operamos el servicio de streaming de terceros: * **Audited and re-tuned the flight's capacity profile** so individual servers have substantially more headroom for concentration load, and worked with the provider to resolve the scaling limitation found during the incident. En curso: * **La tasa de conocimiento de la capacidad limita** — cerrando las brechas entre los límites de la tasa de proyecto concedidos individualmente y la capacidad real de cada proyecto, ampliando la tasa limitando a las vías de ingestión que anteriormente carecían de ella, y acoplando cualquier límite futuro aumenta a un aumento de la capacidad, que está diseñado para evitar que esta clase de desalineación vuelva a repetirse.. * ** Monitorización y alerta de volumen afinado** para detectar y corregir la desalineación de la capacidad antes de que pueda afectar a cualquier cliente. * Evaluando una mayor asignación de prioridades de recuperación de la carga de trabajo/recuperación atrasada para las rutas de tráfico a granel/relleno, por lo que las importaciones históricas han reducido sus efectos en el tráfico en vivo # Common questions * ** ¿Se perdieron datos?** No. Los eventos fueron duramente consultados durante todo el incidente y fueron procesados completamente una vez que el atraso se despejó. Cualquier gota métrica vista durante la ventana fue un artefacto de visualización del retraso y autocorregido. * **¿Necesito coordinar grandes importaciones o backfills con Mixpanel?** No. Nuestro objetivo es que la plataforma mantenga cualquier importación dentro de las tarifas seguras automáticamente, para que los backfills y los sincronizadores de almacén puedan funcionar sin programar o notar. Todavía estamos desplegando los controles de capacidad que proporcionan esto. Mientras tanto, si usted está planeando una importación o relleno inusualmente grande, recomendamos coordinar con su equipo de cuenta para que podamos confirmar la capacidad por adelantado. * **¿Cómo se impide esto avanzar?** La solución sistémica está reforzando las brechas entre los límites de la tasa de proyecto concedidos individualmente y la capacidad real de cada proyecto, y ampliando la tasa limitando a las vías de ingestión que anteriormente carecían de ella, por lo que la sobrecarga de este tipo se detiene al ingreso. Además, la limitación de escalado que prolonga el incidente se fija, el oleoducto ahora retrae elementos de problemas individuales por separado para que una sobrecarga localizada tenga mucho menos impacto en el tráfico no relacionado, y el tráfico a granel está siendo más aislado del tráfico en vivo. * **¿Pueden priorizarse los proyectos individuales durante la recuperación?** Esta capacidad no existía durante el incidente, todos los proyectos recuperados al mismo ritmo. Estamos evaluando mecanismos de priorización para la recuperación atrasada como parte de nuestro trabajo de seguimiento. Nos disculpamos por la perturbación y por la preocupación que causaron las métricas temporalmente deprimidas. Por favor, contacte a través de su equipo de cuenta o apoyo con cualquier pregunta.

Traducido automáticamente desde la actualización oficial del incidente.

1. 29 de junio de 2026 a las 19:47 UTCinvestigating

   Mixpanel está experimentando un rendimiento degradado con nuestra API de consulta, incluyendo mayor latencia. Puede ver informes de carga lenta o errores de consulta. Apreciamos su paciencia mientras nuestros ingenieros trabajan para restaurar la funcionalidad normal. Publicaremos actualizaciones de progreso en nuestra página de estado. Si tiene alguna pregunta, por favor contacte con soporte.

2. 29 de junio de 2026 a las 21:04 UTCidentified

   Se ha determinado la cuestión y se está aplicando una solución.

3. 29 de junio de 2026 a las 22:42 UTCidentified

   Latencia de consultas se ha estabilizado, aunque nuestro equipo sigue investigando la causa subyacente del rendimiento degradado. Seguiremos publicando actualizaciones a medida que avance nuestra investigación. Gracias por su paciencia.

4. 30 de junio de 2026 a las 2:15 UTCmonitoring

   Se ha aplicado una solución y estamos monitoreando los resultados.

5. 30 de junio de 2026 a las 3:30 UTCresolved

   Este incidente ha sido resuelto.

Traducido automáticamente desde la actualización oficial del incidente.

1. 3 de junio de 2026 a las 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 de junio de 2026 a las 20:17 UTCidentified

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

3. 3 de junio de 2026 a las 21:27 UTCresolved

   This incident has been resolved.

1. 2 de junio de 2026 a las 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 de junio de 2026 a las 12:31 UTCidentified

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

3. 2 de junio de 2026 a las 14:31 UTCmonitoring

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

4. 2 de junio de 2026 a las 16:53 UTCresolved

   This incident has been resolved.

1. 1 de junio de 2026 a las 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 de junio de 2026 a las 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 de junio de 2026 a las 15:29 UTCidentified

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

4. 1 de junio de 2026 a las 16:38 UTCmonitoring

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

5. 1 de junio de 2026 a las 19:42 UTCresolved

   This incident has been resolved.

1. 19 de mayo de 2026 a las 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 de mayo de 2026 a las 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 de mayo de 2026 a las 20:23 UTCmonitoring

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

4. 19 de mayo de 2026 a las 21:18 UTCresolved

   This incident has been resolved.

1. 14 de mayo de 2026 a las 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 de mayo de 2026 a las 23:48 UTCidentified

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

3. 15 de mayo de 2026 a las 10:19 UTCidentified

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

4. 15 de mayo de 2026 a las 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 de mayo de 2026 a las 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 de mayo de 2026 a las 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 de mayo de 2026 a las 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 de mayo de 2026 a las 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 de mayo de 2026 a las 21:23 UTCidentified

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

10. 15 de mayo de 2026 a las 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 de mayo de 2026 a las 0: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 de mayo de 2026 a las 1:52 UTCmonitoring

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

13. 16 de mayo de 2026 a las 2:50 UTCresolved

    This incident has been resolved.

14. 21 de mayo de 2026 a las 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 de mayo de 2026 a las 16:34 UTCidentified

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

2. 13 de mayo de 2026 a las 21:40 UTCidentified

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

3. 14 de mayo de 2026 a las 13:35 UTCresolved

   This incident has been resolved.

1. 12 de mayo de 2026 a las 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 de mayo de 2026 a las 17:46 UTCidentified

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

3. 12 de mayo de 2026 a las 20:24 UTCmonitoring

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

4. 12 de mayo de 2026 a las 21:44 UTCresolved

   This incident has been resolved.

1. 6 de mayo de 2026 a las 0: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 de mayo de 2026 a las 9: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 de mayo de 2026 a las 20:04 UTCresolved

   This incident has been resolved.

1. 9 de abril de 2026 a las 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 de abril de 2026 a las 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 de abril de 2026 a las 21:44 UTCresolved

   This incident has been resolved.

1. 16 de marzo de 2026 a las 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 de marzo de 2026 a las 19:29 UTCmonitoring

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

3. 16 de marzo de 2026 a las 21:47 UTCresolved

   This incident has been resolved.

1. 2 de marzo de 2026 a las 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 de marzo de 2026 a las 21:09 UTCidentified

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

3. 2 de marzo de 2026 a las 21:09 UTCmonitoring

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

4. 2 de marzo de 2026 a las 21:53 UTCresolved

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