Degraded Service for Requests to decide.mixpanel.com
Início 21 Here 2026 da 18:04 UTC · 2h 11m
Pending
monitoring
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.
resolved
This incident has been resolved.
Serviço Degradado para Solicitações para decidir.mixpanel.com
Início 21 Here 2026 da 18:00 UTC · 7h 33m
Pending
monitoring
Recebemos relatórios de que pedidos para decidir.mixpanel.com estão falhando.
Qualquer tráfego enviado através de decide.mixpanel.com pode ser afetado, incluindo sinalizadores de recursos e rastreamento de eventos.
Para restaurar o serviço agora, aponte solicitações para api.mixpanel.com (US), api-eu.mixpanel.com (EU), ou api-in.mixpanel.com (IN), dependendo da Residência de Dados do seu projeto.
Fizemos uma mitigação e estamos a monitorizar os resultados. Estamos a ver o trânsito restaurado.
Publicaremos atualizações de progresso em nossa página de status.
Se tiver alguma dúvida, contacte o suporte.
resolved
Este incidente foi resolvido.
postmortem
# **Mixpanel RCA: Pedidos para** [**decide.mixpanel.com**](http://decide.mixpanel.com)**Falhou, 15–21 de outubro de 2026**
### **Resumo#
De 15 de outubro de 2026 a 21 de outubro de 2026, pedidos enviados para `decide.mixpanel.com` e `api-decide.mixpanel.com` falharam.
Isso afetou os clientes que enviaram o rastreamento de eventos, atualizações de perfil ou solicitações de flag para este hostname, geralmente através de um proxy.
Os eventos enviados para este domínio durante esta janela não foram recebidos pelo Mixpanel e estes dados não podem ser restaurados pelo Mixpanel.
**Traffic enviado para** `api.mixpanel.com`**,** `api-js.mixpanel.com,` `api-eu.mixpanel.com`**, e** `api-in.mixpanel.com`** não foram afetados.**
O serviço neste hostname foi involuntariamente impactado enquanto estávamos removendo a infraestrutura de endpoint `/decide`. Os nomes dos hospedeiros foram tratados como parte do desfecho devido à compreensão incorreta das dependências do sistema. Para evitar essa classe de problema, estamos adicionando monitoramento de tráfego para os hostnames `decide.mixpanel.com` e `api-decide.mixpanel.com`. Também exigiremos tráfego zero confirmado no nível hostname antes de qualquer hostname ser removido.
** Desde então temos o serviço restaurado em** `decide.mixpanel.com` .
O que aconteceu?
Older Mixpanel SDKs chamou o endpoint `/decide` para buscar a configuração para [**Legacy Automatically Tracked Mobile Events**](https://docs.mixpanel.com/docs/tracking-methods/sdks/ios#legacy-automatically-tracked-events). Nós [annunciamos a aposentadoria do endpoint](https://docs.mixpanel.com/changelogs#2026-01-26), e por algum tempo `/decide` retornou uma resposta `410`.
Separadamente, `decide.mixpanel.com` e `api-decide.mixpanel.com` atuaram como apelidos para nossos hostnames API padrão. Por exemplo, `decide.mixpanel.com/track` ingeriu eventos da mesma forma que `api-js.mixpanel.com/track`. Alguns clientes configuraram proxies ou configurações SDK para enviar seu tráfego para esses nomes de host.
Em 15 de outubro às 7:40 PM CDT, durante a limpeza final do endpoint `/decide`, removemos os registros DNS para `decide.mixpanel.com` e `api-decide.mixpanel.com' e removemos ambos os nomes de host do nosso balanceador de carga.
Antes de fazer a mudança, confirmamos que o tráfego para o endpoint `/decide` caiu para zero. No entanto, nosso monitoramento mediu o tráfego pelo endpoint e não pelo hostname. Não mostrou, portanto, que outras solicitações, como `/track` e `/flags`, ainda estivessem alcançando Mixpanel através desses nomes de host.
A partir de então, todas as solicitações para este hostname falharam, incluindo terminais como `/track`, `/engage`, `/groups` e `/flags`.
* **Eventos e Perfis:** Eventos, Perfis e quaisquer dados destinados a [Endpoints da API de ingestão](https://docs.mixpanel.com/reference/ingestion-api) a estes nomes de host durante esta janela nunca chegou a Mixpanel, então não temos uma cópia para restaurar. Se você reteve esses dados em outro lugar, como em logs proxy ou seu data warehouse, você pode reenviar para a API da Ingestion [/import](https://docs.mixpanel.com/reference/import-events), [/engage,](https://docs.mixpanel.com/reference/profile-set) e [/groups](https://docs.mixpanel.com/reference/group-set-property).
* ** Bandeiras de características:** Os pedidos de bandeira de funcionalidades enviados para estes nomes de máquinas falharam. Os SDKs serviram a última variante armazenada se uma existisse, ou de outra forma o valor de reserva configurado em seu código.
Linha do Tempo \(Tempo Central, Outubro 2026\)
* ** 15 de outubro, 7:40 PM CDT:** A remoção do nome da máquina é aplicada. Pedidos para `decide.mixpanel.com` e `api-decide.mixpanel.com` começam a falhar.
* 16 de outubro, 5:22 CDT:** Recebemos o primeiro relatório do cliente. Entende-se, inicialmente, estar relacionado à aposentadoria planejada.
* 21 de outubro, 11:42 CDT: Após um aumento nos relatórios de clientes sobre falha de rastreamento para proxies, identificamos a remoção do nome do host como a causa.
* 21 de outubro, 12:26 PM CDT:** Restauramos os nomes das máquinas. «/decidir» continua reformado.
* 21 de outubro, 1:51 PM CDT:** Confirmamos que o tráfego para os nomes restaurados se recuperou.
* 21 de Outubro, 8:34 PM CDT:** O incidente está resolvido.
# # # Causa da raiz #
1. Durante a aposentadoria '/decide', 'decide.mixpanel.com' e 'api-decide.mixpanel.com' foram involuntariamente removidos.
2. Estes hostnames tinham sido configurados para aceitar todo o tráfego de API, não só `/decide` requisições, e este comportamento foi indocumentado.
3. Nosso monitoramento rastreou o tráfego para o endpoint `/decide` mas não para estes hostnames, então as verificações pré-mudança não mostraram que outro tráfego ainda estava ativo.
4. Como os hostnames e o endpoint aposentado compartilham um nome, os primeiros relatórios de clientes foram inicialmente interpretados como efeitos esperados da aposentadoria anunciada `/decide`. Esta escalada tardia.
O que estamos a mudar
* ** Monitorização e alerta: ** Estamos adicionando monitoramento de tráfego e taxa de erro e alerta para `decide.mixpanel.com' e `api-decide.mixpanel.com', então falhas são detectadas automaticamente em vez de através de relatórios de clientes.
* ** Auditoria do nome: ** Nós estamos auditando todos os hostnames públicos API e roteando aliases para pontos de entrada não documentados semelhantes, e vamos rever novos hostnames e aliases antes de eles ir ao vivo. Também estamos rastreando tráfego que chega em qualquer nome de host inesperado.
* Remoções de segurança:** Antes de qualquer mudança futura para um nome de host público, vamos confirmar o tráfego zero no nível de hostname, e vamos identificar e contatar quaisquer projetos que ainda o utilizem.
* ** Comunicação ao cliente: ** Nós daremos aos clientes aviso prévio de mudanças de infraestrutura materiais que afetam os nomes de host públicos, incluindo publicá-los em uma linha do tempo em nosso changelog.
**Já implantado:**
* Restaurado `decide.mixpanel.com` e `api-decide.mixpanel.com'
* `/decide` permanece aposentado
Perguntas comuns
* ** Meus dados foram afetados?** Somente se o seu SDK ou proxy enviou pedidos para `decide.mixpanel.com` ou `api-decide.mixpanel.com` entre 15 de outubro e 21 de outubro. Os dados enviados durante essa janela não foram recebidos e não podem ser restaurados pelo Mixpanel. Se você reteve uma cópia desses dados, você pode reenviar para o Mixpanel usando nossos endpoints da API de ingestão, como `/importar` para eventos.
Preciso de mudar alguma coisa? Não, os domínios funcionam novamente. Recomendamos o uso de `api.mixpanel.com` \(ou `api-eu.mixpanel.com` / `api-in.mixpanel.com` para residência de dados UE e Índia\) como seu domínio API.
* ** '/decide' está voltando? Não. Ele permanece aposentado como anunciado, e é separado do nome de host `decide.mixpanel.com`.
Lamentamos a interrupção. Se você tiver dúvidas sobre seu projeto, entre em contato com sua equipe de contas ou o Suporte Mixpanel.
Traduzido automaticamente da atualização oficial do incidente.
Atraso temporário de ingestão de dados para projetos dos EUA
Início 8 Here 2026 da 16:32 UTC · 7h 50m
Pending
investigating
Estamos atualmente passando por atrasos em nosso pipeline de ingestão de dados, que está afetando dados em tempo real para projetos inscritos nos projetos dos EUA, resultando em atrasos para um subconjunto de projetos. Enquanto nenhum dado está sendo perdido, nossa equipe de engenharia está ativamente investigando o assunto e trabalhando para restaurar a funcionalidade em tempo real o mais rápido possível. Agradecemos a sua paciência durante este tempo.
Se tiver alguma dúvida, contacte o suporte.
identified
A questão foi identificada e está a ser implementada uma solução.
identified
Identificamos a causa do atraso na ingestão como um problema inicial com nosso provedor de armazenamento em nuvem, o Google Cloud, impactando um subconjunto de projetos dos EUA. O Google confirmou isso como um problema de alta prioridade no seu final, mas ainda não forneceu um ETA. Implantamos mitigação para garantir uma recuperação suave assim que se desvanecer.
Nenhum evento está sendo perdido. Este é estritamente um atraso de ingestão, todos os dados afetados continuarão a ser reprocessados uma vez que o problema é resolvido.
monitoring
As nossas métricas mostram que a ingestão é apanhada e já não sofre atrasos. O Google ainda não confirmou a resolução do problema subjacente a montante no seu fim, por isso continuamos a monitorizar de perto em caso de recorrência.
monitoring
Nenhuma mudança desde nossa última atualização, continuamos a observar nenhum atraso na ingestão ativa do nosso lado, e todos os sistemas permanecem saudáveis. Continuamos a monitorar de perto.
monitoring
Continuamos monitorando quaisquer outros problemas.
monitoring
Os sistemas permaneceram estáveis sem recorrência do atraso na ingestão. Estamos de olho nas coisas enquanto esperamos pela confirmação final do nosso provedor upstream.
resolved
Este incidente foi resolvido. O problema upstream com o nosso provedor de armazenamento em nuvem foi corrigido, e nosso pipeline de ingestão tem funcionado normalmente sem atrasos ativos. Nenhum evento foi perdido ao longo deste incidente, todos os dados afetados foram totalmente reprocessados.
Obrigado pela vossa paciência durante todo este incidente.
Traduzido automaticamente da atualização oficial do incidente.
API de Consulta Degradada Desempenho impactando Projetos EUA
Início 26 Eost 2026 da 21:39 UTC · 1h 7m
OutageMajor incident
Componentes afetados
Application Availability (US)
investigating
Mixpanel está experimentando o desempenho da API da Consulta degradada, resultando em respostas HTTP 500 ao consultar relatórios para projetos com a Residência de Dados dos EUA. Os projectos com a UE e a Residência de Dados não são afectados.
Agradecemos sua paciência enquanto nossos engenheiros trabalham para restaurar a funcionalidade normal. Publicaremos atualizações de progresso em nossa página de status.
Se tiver alguma dúvida, contacte o suporte.
identified
A questão foi identificada e está a ser implementada uma solução.
monitoring
Uma correção foi implementada, e estamos vendo taxas de sucesso melhoradas para a API Consulta. Continuaremos a acompanhar para garantir a estabilidade.
resolved
Este incidente foi resolvido.
postmortem
# Mixpanel RCA: Interrupção do Serviço de Consulta Temporária para Projetos dos EUA 26 de agosto de 2026
Resumo
Entre aproximadamente **2:02 PM e 3:19 PM PT em 26 de agosto de 2026**, projetos na região dos EUA experimentaram falhas no carregamento de relatórios e execução de consultas através da Mixpanel UI e Consulta API. Durante esta janela, algumas consultas na região falharam ou retornaram erros. ** Nenhum dado do cliente foi perdido, e a ingestão de dados não foi afetada. ** Todos os eventos continuaram sendo coletados e armazenados normalmente durante todo o incidente; uma vez que o serviço de consulta foi restaurado, todos os relatórios refletiam dados completos e precisos, sem necessidade de ação do cliente.
A causa foi identificada como uma ferramenta interna recentemente implantada para replay de consulta diagnóstica, uma capacidade que nossos engenheiros usam para re-executar cópias de consultas passadas para depurar o desempenho, que inesperadamente escreveu grandes quantidades de dados para os discos de nossos servidores de consulta, consumindo capacidade de armazenamento que os servidores precisam operar. Quando esses discos foram preenchidos, os servidores afetados saíram do serviço. Serviço foi restaurado, os servidores impactados foram trazidos de volta on-line, eo ferramental interno foi desativado. As remediações abaixo adicionam salvaguardas de armazenamento para remover a capacidade interna de ferramentas de consumir recursos em servidores de consulta, e são projetadas para evitar que essa classe de falha aconteça novamente no futuro.
# O que aconteceu
O mecanismo de consulta da Mixpanel é executado em uma frota de servidores que cada um usa um conjunto de volumes de armazenamento local para armazenar os dados necessários para responder consultas rapidamente. Separadamente, nossos engenheiros usam ferramentas de replay de consultas diagnósticas, uma capacidade que nossos engenheiros usam para reproduzir e depurar o desempenho da consulta.
Ao aplicar a ferramenta de replay de consulta diagnóstica a uma consulta grande e complexa, um bug de software fez com que a replay de consulta capturasse toda a frota em vez de permanecer confinado a um único servidor. Além disso, causou muito mais dados do que pretendia ser salvo sem despejo oportuno em um único servidor. Em seguida, dois fatores ampliaram o impacto da questão:
* Um único volume de armazenamento completo levou um servidor completamente fora de serviço. Cada servidor trata seu cache como não saudável se qualquer um de seus volumes de armazenamento cruzar um limiar de uso, mesmo quando todos os outros volumes são saudáveis. Os dados de repetição foram escritos para um volume específico em cada servidor, de modo que os servidores em toda a região falharam em suas verificações de saúde quase simultaneamente.
* Limites de limpeza não contabilizam o tamanho dos dados. A salvaguarda limitando dados de repetição no disco contou itens no nível da aplicação em vez de bytes no nível do sistema de arquivos, então um pequeno número de captura inesperadamente grandes passou a verificação enquanto consumia a maior parte da capacidade do volume.
Juntos, estes permitiram um único fluxo de trabalho de depuração que normalmente tem uma pegada insignificante para interromper a consulta de produção servindo em toda a região dos EUA.
# Timeline \(Tempo Pacífico, 26 de agosto de 2026\)
* ** 2:00 PM** — Primeira captura de replay de diagnóstico superdimensionada foi escrita; volumes de armazenamento começaram a atingir sua capacidade e taxa de sucesso da consulta começou a cair pouco depois.
* **2:17 PM** — Alerta automático chamou o engenheiro de plantão; a investigação começou imediatamente e engenheiros adicionais foram envolvidos.
* **2:39 PM** — Incidente de página de status postado; banner no aplicativo exibido às 2:40 PM.
* **2:53 PM** — Causa raiz identificada; os esforços de recuperação começaram no primeiro grupo de servidor afetado.
* **3:19 PM** — Serviço de consultas restaurado para a grande maioria do tráfego; o grupo de servidor final totalmente recuperado às 3:27 PM.
* 3:45 PM** — Incidente resolvido após um período de observação estável. A ferramenta de repetição diagnóstica que desencadeou o problema foi totalmente desativada na mesma noite.
Causa raiz
1. **Um bug de software em nossa ferramenta de replay de consulta causado unbounded escreve ao armazenamento de produção.** Uma capacidade recentemente implantada para reproduzir consultas manuseou uma determinada classe de consultas complexas, fazendo com que as capturas se espalhassem para cada servidor de consultas na região e escrevessem muito mais dados para os volumes afetados do que o projeto assumido.
2. **Replay arquivos consumidos capacidade de disco que serviço de consulta depende.** O replay tooling escreveu seus arquivos para os discos locais dos servidores de consulta, então a capacidade de armazenamento esgotada de dados de replay em fuga que os servidores precisam responder às consultas.
3. ** As salvaguardas apenas parcialmente contabilizadas para o comportamento. ** A política de limpeza para dados de replay diagnóstico limitou o número de itens no disco, mas não o seu tamanho total, por isso não engajou. Alertar sobre volumes de armazenamento marcou o crescimento, mas não foi escalado como crítico em uma base por servidor, que atrasou a detecção até que as falhas da consulta começaram.
O que estamos a mudar
O estado final que estamos construindo para: dados internos de replay de consulta diagnóstica armazenados em armazenamento de objetos dedicado, não colocando carga em servidores de produção de consulta.
Já implantado:
* **Desativado o tooling interno** que causou o incidente, e remediado o problema subjacente para que as capturas diagnósticas são confinadas a um único servidor e a classe de consulta específica é tratada corretamente.
* **Documentado o procedimento de recuperação direcionado** usado durante o incidente, ou seja, limpando apenas o volume de armazenamento afetado em vez de reiniciar grupos de servidores completos, em nossos runbooks operacionais, encurtando o tempo de recuperação se a capacidade de qualquer volume se esgotar no futuro.
Em progresso:
* **Filesystem-level, tamanho-based limites em dados de replay diagnóstico**, capping bytes totais no disco em vez de contagens de itens, então capturas superdimensionadas são rejeitadas ou despejadas antes que possam afetar a capacidade do volume.
* **Stricter storage alertando**, aumentando a saturação de volume por servidor como crítico antes que possa afetar a verificação de saúde da consulta.
* **Movendo dados de replay de consulta para o armazenamento de objetos dedicado,** então ele não consome recursos em servidores de consulta de produção.
Perguntas comuns
* ** Algum dado foi perdido?** Não. A ingestão de dados não foi afetada durante todo o incidente: os eventos continuaram a ser coletados, em fila e armazenados normalmente. Apenas a capacidade de consulta foi interrompida. Uma vez que o serviço foi restaurado, todos os relatórios refletiam dados completos.
* ** Foram afetados relatórios salvos, painéis ou configurações de projeto?** Não. O incidente afetou apenas a execução da consulta. Nada armazenado no seu projeto mudou.
* ** Por que afetou vários projetos americanos ao mesmo tempo?** Os dados sobredimensionados de replay de diagnóstico escritos nos discos de cada servidor de consulta quase ao mesmo tempo, e cada servidor se remove do serviço quando qualquer volume preenche. A prevenção de ferramentas internas de consumir o armazenamento de servidor de consultas é uma parte essencial do nosso trabalho de remediação.
* ** Como isso é impedido de ir em frente?** O problema do ferramental é resolvido e o ferramental permanece desativado até que os limites baseados no tamanho estejam em vigor. O alerta de armazenamento está sendo apertado, então a saturação é captada antes de afetar o serviço de consulta. Estruturalmente, estamos movendo os dados de diagnóstico para fora dos servidores de pesquisa de produção inteiramente, então dados internos de depuração não consumirão armazenamento nos servidores responsáveis pelo processamento de consultas.
Pedimos desculpa pela interrupção e pelo tempo que os relatórios não estavam disponíveis. Por favor, entre em contato com sua equipe de conta ou suporte com quaisquer perguntas.
Traduzido automaticamente da atualização oficial do incidente.
Problemas Populando Propriedades do Evento em menus suspensos
Atualmente estamos tendo problemas com a povoação de propriedades de eventos em menus suspensos. Agradecemos sua paciência enquanto nossos engenheiros trabalham para restaurar a funcionalidade. Se tiver alguma dúvida, contacte [email protected]
identified
Continuamos trabalhando em uma solução para esse problema.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
We are aware that the Get-Report tool in the Mixpanel MCP server is currently failing when called with skip_results: false. Report metadata is unaffected. We are investigating the issue and will provide updates as we have them.
identified
The issue has been identified and fix is being implemented.
monitoring
A fix has been deployed and we're now monitoring the results. Report queries in the Mixpanel MCP server should be functioning normally. We'll continue to watch closely and provide a final update once we've confirmed full resolution.
resolved
This incident has been resolved.
Questões que servem respostas do agente Mixpanel
Início 22 Gouere 2026 da 08:03 UTC · 6h 44m
Pending
investigating
Atualmente estamos tendo problemas com o agente Mixpanel dentro do webapp. Nossa equipe de engenharia foi alertada e está investigando o problema e trabalhando para restaurar sua funcionalidade. Agradecemos a sua paciência enquanto trabalhamos para resolver este assunto.
Se tiver alguma dúvida, contacte o suporte.
investigating
a equipe continua a investigar a questão e os próximos passos. Obrigado pela paciência.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Atraso temporário de ingestão de dados para projetos dos EUA
Início 11 Gouere 2026 da 07:53 UTC · 8h 1m
IssuesMinor incident
Componentes afetados
Ingestion API Availability (US)
investigating
Estamos atualmente passando por atrasos em nosso pipeline de ingestão de dados, que está afetando dados em tempo real para projetos inscritos nos projetos dos EUA, resultando em atrasos para um subconjunto de projetos. Enquanto nenhum dado está sendo perdido, nossa equipe de engenharia está ativamente investigando o assunto e trabalhando para restaurar a funcionalidade em tempo real o mais rápido possível. Agradecemos a sua paciência durante este tempo.
Se tiver alguma dúvida, contacte o suporte.
investigating
Continuamos a investigar esta questão.
identified
A questão foi identificada e está a ser implementada uma solução.
identified
Continuamos trabalhando em uma solução para esse problema.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
postmortem
Resumo
Entre aproximadamente **11:35 PM PT em 10 de julho e 7:19 AM PT em 11 de julho de 2026**, a ingestão de dados para projetos Mixpanel na região dos EUA correu para trás por até ~2 horas. Durante esta janela, relatórios e painéis mostraram temporariamente dados incompletos — os intervalos de tempo recentes podem aparecer como quedas artificiais em métricas como usuários ativos ou receita. ** Nenhum dado foi perdido. Todos os eventos foram enfileirados duravelmente e processados na íntegra, uma vez que o backlog limpou; as métricas retornaram aos valores exatos por conta própria, sem necessidade de ação do cliente.
A causa originou-se em nossos controles de ingestão: para um pequeno número de projetos de muito alto volume, as taxas de ingestão que permitimos tinham saído de alinhamento com a capacidade provida para esses projetos. As grandes importações históricas — utilização inteiramente legítima da plataforma — foram, portanto, admitidas mais rapidamente do que a sua infra-estrutura poderia absorver, e duas propriedades do nosso gasoduto transformaram essa sobrecarga localizada num atraso regional. As correções abaixo realinham esses controles para que qualquer importação, de qualquer tamanho, seja automaticamente mantida dentro de limites seguros.
# O que aconteceu
O pipeline de ingestão da Mixpanel é desfiado e multi-atendimento: os dados de cada projeto são distribuídos em um conjunto de partições de tamanho para o seu volume esperado, e para o rendimento, os eventos de muitos clientes são processados em lotes. Este design oferece alta eficiência, mas depende de um invariante: a taxa em que admitimos o tráfego de um projeto deve corresponder à capacidade provida para ele. Quando esse invariante se detém, mesmo importações muito grandes são absorvidas sem problemas.
Aqui, não aguentou. Um pequeno número de grandes importações de dados históricos foi realizado em projetos cujas taxas de ingestão permitidas tinham, ao longo do tempo, crescido bem além de sua capacidade de partição provida. O excesso de volume se concentrou em partições específicas como **pontos quentes**, saturando a porção da frota de streaming que os serve. Dois factores alargaram o impacto:
* ** O processamento multi-atendimento amplificado dos pontos quentes.** Porque os eventos de muitos clientes viajam juntos em lotes, lentidão e falhas nas partições sobrecarregadas atrasaram os eventos de clientes independentes compartilhando esses lotes.
* ** O aumento automático foi ineficaz. A capacidade de adição não pode dissolver um ponto quente deste tipo, porque as divisórias sobrecarregadas permanecem presas à mesma infra-estrutura, e um limite de capacidade em um componente da nossa infraestrutura de streaming impediu que a capacidade adicional entrasse em vigor.
Juntos, estes transformaram o que deveria ter sido um breve, auto-cura desaceleração em um atraso de várias horas que requer intervenção manual.
# Linha do Tempo \(Tempo Pacífico, 10-11 de julho\)
* **11:35 PM** — Alerta automático detectou o atraso de ingestão; engenheiro de plantão ativado imediatamente.
* **12:49 AM** — Incidente de página de status publicado; impacto apenas na região dos EUA.
* **1:23 A maior importação contribuinte foi pausada.
* **1:55-6:48 AM** — mitigação progressiva: fontes de tráfego adicionais aceleradas, certos dados atrasados diferidos com o acordo do próprio cliente, isolamento de falhas habilitado no gasoduto, e nós de infraestrutura afetados substituídos.
* **7:19 AM** — Backlog totalmente processado; todos os projetos atuais. Página de status mudou para monitoramento, então resolvido após um período de observação estável.
Causa raiz
1. **Limites de taxa de ingestão desalinhados com capacidade provida. ** Para os projetos de condução, as taxas admitidas pela nossa plataforma cresceram fora de passo com a infra-estrutura fornecida para eles, então as legítimas importações de alto volume foram introduzidas mais rapidamente do que suas divisórias poderiam absorver. Esta é a causa da raiz sistémica. As próprias importações constituíam uma utilização legítima da plataforma.
2. ** O processamento de múltiplos inquilinos amplificaram a sobrecarga. ** Falhas nas partições sobrecarregadas atrasaram os eventos de clientes independentes compartilhando os mesmos lotes de processamento, espalhando um problema localizado pela plataforma.
3. ** O tráfego para as partições sobrecarregadas não pôde ser redistribuído. ** A atribuição de partição para servidor na camada de streaming não estava consciente de carga, então os pontos quentes ficaram presos aos mesmos servidores, independentemente do tamanho da frota — capacidade total era suficiente, mas não podia ser trazida para suportar. Um limite de escala em um componente de nossa infraestrutura de streaming compôs isso, impedindo que o aumento de escala aumentasse a capacidade, o que atrasou o diagnóstico até que os engenheiros interviessem manualmente.
O que estamos a mudar
O estado final que estamos construindo para: ** os limites de ingestão de cada projeto correspondem automaticamente à sua capacidade provida, de modo que as importações de qualquer tamanho, incluindo backfills históricos completos e sincronização de data warehouses, podem ser executadas sem coordenação prévia, e o volume de um projeto é impedido de afetar a frescura de dados de outro.**.
Já implantado — melhorando nosso manejo da ingestão:
* ** Manuseamento melhorado do hot-spot.** A distribuição de tráfego na camada de streaming está agora consciente de carga, espalhando a carga concentrada de forma mais uniforme em toda a frota, e os itens individuais de problemas são agora tentados separadamente em vez de segurar o resto de seu lote — reduzindo, embora não eliminando, o impacto que uma sobrecarga localizada pode ter no tráfego não relacionado.
* **Re-forneceu as cargas de trabalho de maior volume** na infraestrutura de tamanho adequado, priorizada pelo risco.
Já implantado — alterando a forma como operamos o serviço de streaming de terceiros:
* **Auditou e reajustou o perfil de capacidade da frota** para que os servidores individuais tenham substancialmente mais headroom para carga concentrada, e trabalhou com o provedor para resolver a limitação de escala encontrada durante o incidente.
Em progresso:
* ** Limitação da taxa de capacidade-consciente** — fechando as lacunas entre limites de taxa de projeto individualmente concedidos e a capacidade real de cada projeto provida, estendendo a taxa limitando aos caminhos de ingestão que antes faltavam, e unindo qualquer aumento de limite futuro a um aumento de capacidade, que é projetado para evitar que esta classe de desalinhamento de recorrente.
* * ** Monitoramento e alerta de volume com fileira** assim que o desalinhamento da capacidade é detectado e corrigido antes que possa afetar qualquer cliente.
* Avaliando o isolamento de carga de trabalho mais forte/priorização de recuperação de backlog para caminhos de tráfego em massa/reenchimento, então as importações históricas têm reduzido o impacto no tráfego vivo
Perguntas comuns
* ** Algum dado foi perdido?** Não. Os eventos foram duravelmente em fila durante todo o incidente e foram totalmente processados uma vez que o backlog limpo. Qualquer gota métrica observada durante a janela foi um artefato de exibição do atraso e autocorrigido.
* **Eu preciso coordenar grandes importações ou backfills com Mixpanel?** Não — Nosso objetivo é que a plataforma mantenha qualquer importação dentro de taxas seguras automaticamente, de modo que backfills e warehouse sincronizs possam ser executados sem agendamento ou aviso prévio. Ainda estamos a desenvolver os controlos de capacidade que permitem isso. Enquanto isso, se você estiver planejando uma importação ou enchimento anormalmente grande, recomendamos a coordenação com sua equipe de conta para que possamos confirmar a capacidade com antecedência.
* ** Como isso é impedido de ir em frente?** A correção sistêmica está apertando as lacunas entre os limites de taxa de projeto individualmente concedidos e a capacidade real de abastecimento de cada projeto, e estendendo a taxa limitando-se aos caminhos de ingestão que antes faltavam — então sobrecarga deste tipo é parada na admissão. Além disso, a limitação de escala que prolongou o incidente é fixa, o gasoduto agora recupera itens individuais problema separadamente, de modo que uma sobrecarga localizada tem muito menos impacto no tráfego não relacionado, e o tráfego a granel está sendo mais isolado do tráfego vivo.
* ** Os projetos individuais podem ser priorizados durante a recuperação?** Esta capacidade não existia durante o incidente — todos os projectos recuperados à mesma taxa. Estamos avaliando mecanismos de priorização para recuperação de backlog como parte de nosso trabalho de acompanhamento.
Pedimos desculpas pela interrupção e pela preocupação causada pelas métricas temporariamente deprimidas. Por favor, entre em contato com sua equipe de conta ou suporte com quaisquer perguntas.
Traduzido automaticamente da atualização oficial do incidente.
Mixpanel está experimentando desempenho degradado com nossa API de Consulta, incluindo o aumento da latência. Você pode ver relatórios de carregamento lento ou erros de consulta. Agradecemos sua paciência enquanto nossos engenheiros trabalham para restaurar a funcionalidade normal. Publicaremos atualizações de progresso em nossa página de status.
Se tiver alguma dúvida, contacte o suporte.
identified
A questão foi identificada e está a ser implementada uma solução.
identified
A latência da consulta estabilizou, embora nossa equipe continue investigando a causa subjacente do desempenho degradado. Continuaremos a publicar actualizações à medida que a nossa investigação avança. Obrigado pela vossa paciência.
monitoring
Foi implementada uma correção e estamos monitorando os resultados.
resolved
Este incidente foi resolvido.
Traduzido automaticamente da atualização oficial do incidente.
Issue with Inviting and Deleting Users
Início 3 Mezheven 2026 da 20:05 UTC · 1h 22m
Pending
investigating
Mixpanel is currently experiencing a disruption in the ability to invite and delete internal users within organizations. We appreciate your patience while our engineers work to restore this functionality. If you have any questions, please contact [email protected]
identified
The issue has been identified and a fix is being implemented.
resolved
This incident has been resolved.
Temporary Data Ingestion Delay for US, India and EU projects
Início 2 Mezheven 2026 da 11:02 UTC · 5h 51m
Pending
investigating
We are experiencing delays with our data ingestion and shuffling pipeline to projects with all projects. No data is being lost but as a result, real-time data is delayed. We appreciate your patience while our engineers work to restore real-time functionality. If you have any questions, please contact support
identified
The issue has been identified and a fix is being implemented.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
Temporary Data Ingestion Delay for US, India and EU projects
We are experiencing delays with our data ingestion and shuffling pipeline to projects with US & India data residency. No data is being lost but as a result, real-time data is delayed. We appreciate your patience while our engineers work to restore real-time functionality. If you have any questions, please contact support
investigating
We have now identified an ingestion delay for EU projects, and are continuing to investigate the issue. Thank you for your patience.
identified
The issue has been identified, and a fix is being implemented.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
Board Access Issues
Início 19 Mae 2026 da 19:03 UTC · 2h 15m
Pending
investigating
A subset of users are currently facing issues accessing boards that they previously had access to view. Our Engineering team is actively investigating and will update shortly.
identified
The issues has been identified and a fix is being implemented. As a workaround boards can be explicitly shared with users who are having issues viewing them currently.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
Query API degraded performance
Início 14 Mae 2026 da 23:17 UTC · 1d 3h
IssuesMinor incident
Componentes afetados
Application Availability (US)
investigating
We are experiencing degraded performance with our Query API, including increased latency. You may see slow-loading reports, incomplete query results, query errors, or data discrepancies. We appreciate your patience while our engineers work to restore normal functionality. We will post progress updates on our status page. If you have any questions, please contact support.
identified
The issue has been identified and a fix is being implemented.
identified
We are continuing to work on a fix for this issue.
identified
We've continued to make progress on the issue affecting some US projects. Query success rates have returned to normal levels, and the related processing delays have also recovered.
A subset of affected projects may still see incomplete data in query results while our recovery process runs. We're actively working on this and will share another update in 2 hours.
Impact remains limited to our US region. We do not currently believe any data has been permanently lost.
identified
Recovery is progressing well. Query success rates remain at normal levels, and missing data has now been restored for a portion of affected projects.
We're continuing the recovery process for the remaining affected projects and currently estimate full recovery within approximately 3–5 hours.
Some customers may still see incomplete data in query results until this work is complete.
identified
We are continuing to work on resolving this issue. Our current estimate for full recovery is approximately 3–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.
identified
Recovery is continuing to progress and query latency has returned to normal levels. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.
identified
We are investigating an increase in query latency that appears to be unrelated to the ongoing recovery. You may experience slower-loading reports. Our team is actively looking into the cause and we will provide an update shortly.
Recovery is continuing to progress. Our current estimate for full recovery is approximately 3–4 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.
identified
Query latency has returned to normal levels. We are continuing to monitor.
identified
Query latency has returned to normal levels and has been resolved.
Recovery is continuing to progress, and our current estimate for full recovery is approximately 4–5 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.
identified
Recovery is continuing to progress. Our current estimate for full recovery is approximately 1-2 hours. Some customers may still see incomplete data in reports until recovery is complete. We will continue to provide updates.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
postmortem
# Mixpanel RCA: Transient Data Access Issue, May 14, 2026
## Summary
On Thursday, May 14, 2026 at approximately 2:30 PM PT, a routine but infrequent cleanup operation in Mixpanel's storage system mistakenly removed a portion of production data files in addition to the unused files it was intended to remove. Some customers experienced query errors during the hours that followed. We detected the issue within minutes, deployed mitigations the same evening that returned query success rates and latency to normal, and restored the affected files from backup by 5:15 PM PT on Friday, May 15. Mixpanel's ingestion pipeline was not affected and no event data was lost in transit.
## What happened
This incident was triggered by a storage cleanup procedure that runs periodically to remove files no longer referenced by Mixpanel's metadata. The procedure was more involved than usual: it followed a recent enhancement to our file storage strategy that left a set of unused files behind in our storage backend, and addressing them required extending our standard cleanup approach to cover a new code path.
As part of executing this extended cleanup, an engineer generated the list of files to delete using a SQL query whose date filter was not strictly earlier than the reference snapshot it was being compared against. As a result, a small set of legitimate production files that had been written in the gap window between the snapshot and the filter date were incorrectly classified as unused and removed.
The deletion ran for roughly half an hour before internal alerting caught the resulting query failures and the operation was stopped. The trigger was operator error against an ambiguous runbook, not a defect in the live serving path or in our ingestion pipeline.
## Customer impact
Impact unfolded in two phases.
The first phase ran from Thursday at approximately 2:30 PM PT until 8:11 PM PT — roughly five and a half hours. During this window, customers across the platform may have seen slower or failed queries when their requests touched files that had been deleted. The breadth and severity varied by project depending on which data each query touched. By 8:11 PM PT, mitigations had fully rolled out — queries automatically retried against an alternate availability zone, and a fallback path was put in place to serve missing files from a backup datastore. After this point, query success rate and latency returned to normal.
The second phase lasted from 8:11 PM PT Thursday through approximately 5:15 PM PT Friday, May 15. During this window, fewer than 2% of customers were still affected — specifically, those whose deleted files had not yet been fully restored from backup. The vast majority of these files were recovered by Friday afternoon. A small number of projects \(under 30\) had files that could not be fully recovered from backup, and we are following up with those accounts directly.
## Timeline \(Pacific Time\)
* May 14, 2:30 PM — Cleanup operation begins
* May 14, 3:11 PM — Internal alerting flags query failures; the cleanup operation is stopped within minutes
* May 14, 4:07 PM — Status page banner posted
* May 14, 4:45 PM — Mitigation deployed: queries automatically retry against an alternate availability zone
* May 14, 7:12 PM — Mitigation deployed: queries fall back to a backup datastore for missing files
* May 14, 8:11 PM — Query success rate and latency fully restored to normal levels
* May 15, 5:15 PM — File restore from backup complete; status page banner resolved
## Why this happened
Several contributing factors lined up.
The runbook for this cleanup procedure had ambiguous wording around the ordering and timing of its inputs. It had been recently authored to handle the new file-storage code path and had not gone through a formal review before being used.
Our cleanup tooling did not programmatically enforce the safety invariant that the date filter must be strictly before the reference snapshot. That invariant lived only in operator-authored SQL.
The extended cleanup was being executed in parallel across two storage layers by two different engineers, which increased the room for error.
## What we're doing to prevent recurrence
We have already made or have actively in flight the following changes.
We are adding programmatic safeguards to our cleanup tooling so that an input set whose date filter is not safely before the reference snapshot is rejected before any deletion occurs, along with a reconciliation step that flags any production-referenced file before deletion proceeds.
Destructive cleanup operations will now run in phased stages, starting with internal projects and pausing for a holding period before any broader execution.
Destructive storage operations now require a second engineer to sign off on the exact deletion set and to be present during execution, matching the practice we already follow for database migrations.
We have updated the cleanup runbook with explicit guidance on input timing, required safety buffers, and an enforced review process for any runbook covering a destructive operation.
Longer term, we are working to eliminate the manual portion of this cleanup procedure entirely and route it through our existing automated cleanup infrastructure, so the class of failure that produced this incident is no longer reachable through human input.
## Closing
Reliability and data integrity are foundational to the trust our customers place in Mixpanel, and we recognize the impact this incident had on the teams who rely on us. We are sorry for the disruption. If you have questions about how this incident may have affected a specific project, please reach out to your account team or Mixpanel Support.
Data Volume Monitoring degraded performance
Início 13 Mae 2026 da 16:34 UTC · 21h 1m
Pending
identified
Data Volume Monitoring is again experiencing degraded performance due to a recurring upstream provider disruption. We're mitigating now.
identified
We are continuing to work on a fix for this issue.
resolved
This incident has been resolved.
Data Volume Monitoring degraded performance
Início 12 Mae 2026 da 17:17 UTC · 3h 57m
Pending
Componentes afetados
Application Availability (US)
investigating
We are currently investigating an issue that leads to degraded performance of Data Volume Monitoring in a subset of US-based projects. We truly appreciate your patience and apologize for the inconvenience. If you have any questions, please contact support (https://mixpanel.com/get-support).
identified
An upstream service provider outage is causing this issue. We are deploying a fix to mitigate the disruption.
monitoring
A fix has been implemented, and we are monitoring the result.
resolved
This incident has been resolved.
Snowflake pipeline exports degraded
Início 6 Mae 2026 da 00:00 UTC · 20h 4m
Pending
investigating
A subset of projects are experiencing issues exporting data to the Snowflake warehouse via Mixpanel pipelines. We are currently investigating this issue.
identified
We have identified the issue affecting Snowflake pipeline exports for a subset of projects, and our engineering team is working on a resolution.
resolved
This incident has been resolved.
Credit Card Processing Interruption
Início 9 Ebrel 2026 da 20:03 UTC · 1h 41m
Pending
identified
We are currently experiencing an interruption with our credit card processing. Our engineers have identified the issue and are working on a fix.
monitoring
A fix has been deployed, and all impacted accounts have had their billing re-run. If you continue to receive errors, please ensure the card on file is up to date. If you are still experiencing issues, please submit a support ticket.
resolved
This incident has been resolved.
Degraded Query API Performance impacting EU Projects
Início 16 Meurzh 2026 da 16:50 UTC · 4h 56m
IssuesMinor incident
Componentes afetados
Application Availability (EU)
identified
Mixpanel is experiencing increased query latency for projects with EU residency, which may result in HTTP 500 responses when querying or saving reports. Projects with US and IN residency remain unaffected. Our engineering team is working on a resolution.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved.
Error loading Mixpanel Webapp
Início 2 Meurzh 2026 da 21:00 UTC · 53m
Pending
investigating
We are currently experiencing issues with loading Mixpanel.com and are working to restore service as quickly as possible. Our team is investigating the issue and will provide updates as soon as we have more information. Thank you for your patience.
identified
The issue has been identified and a fix is being implemented.
monitoring
A fix has been implemented and we are monitoring the results.
resolved
This incident has been resolved. If Mixpanel is still not loading, please clear your cache and cookies.
