Problemas conhecidos
Problemas monitorados e suas resoluções
Primeira request de API após inatividade demora 2-3s a mais
Sua primeira request de API após um período de inatividade leva ~2-3s a mais enquanto o pool de proxy aquece. As requests seguintes respondem normalmente.
Medimos isso novamente em setembro de 2026: a primeira request após um período de inatividade agora é tão rápida quanto as requests seguintes.
Gráficos de uso do dashboard não mostram rótulos de fuso horário
Os gráficos de uso no seu dashboard mostram timestamps em UTC, mas não indicam o fuso horário. Se você estiver fora do UTC, os horários parecem incorretos sem contexto.
Os gráficos e tabelas do dashboard agora exibem todos os horários no seu próprio fuso horário, obtido a partir do seu navegador.
O analytics apresentou uma breve lacuna de dados durante a migração
Durante a migração do banco de dados, o analytics em tempo real ficou indisponível por algumas horas. Nenhum dado foi perdido. A lacuna afetou apenas a visibilidade ao vivo, não os registros históricos.
Preenchemos retroativamente todos os dados históricos (260M+ registros) e verificamos a consistência diária. A ingestão em tempo real retornou em poucas horas.
Usuários do Safari enfrentaram loop de redirecionamento de login no dashboard
Se você usou o Safari, fazer login no dashboard acionava um loop de redirecionamento. Uma peculiaridade no tratamento de cookie do WebKit fazia a sessão falhar entre subdomínios.
Corrigimos os atributos de cookie para compatibilidade entre subdomínios. Agora, o login funciona corretamente em todos os principais navegadores.
Proxies obsoletos permaneceram no pool durante horários de pico
Durante o pico de uso, o pipeline de validação de proxy não conseguiu acompanhar a demanda. Alguns requests atingiram proxies que falharam recentemente antes que o pool os removesse.
Adicionamos health checks paralelos e uma remoção mais rápida de proxies inativos. O pool agora se mantém atualizado mesmo sob uma carga 10x maior que o normal.
Requests do navegador excederam o tempo limite sob cargas pesadas de JS
As requests no modo navegador estavam excedendo o tempo limite em páginas com pacotes pesados de JavaScript. O Chrome headless não tinha memória compartilhada suficiente para lidar com sessões simultâneas.
Aumentamos a memória compartilhada para as sessões do navegador e adicionamos limites de recursos por request. A taxa de tempo limite excedido caiu de ~8% para menos de 0,5%.