Error Tracking: rastreando falhas antes que o usuário reclame

O que é error tracking e por que logs não bastam

Error tracking é a prática de capturar automaticamente exceções e erros não tratados em aplicações, agrupá-los, enriquecê-los com contexto e notificar a equipe de desenvolvimento quando novos problemas surgem. Logs de erro registram que algo falhou, mas geralmente em múltiplas linhas espalhadas entre mensagens de outros processos, sem agrupamento, sem contagem de ocorrências e sem informação sobre quantos usuários foram afetados. Um sistema de error tracking transforma a mensagem de erro e o stack trace em um "issue" estruturado com título, frequência, primeiro e último evento, usuários impactados e histórico de regressões. Enquanto logs são ferramentas de investigação que exigem que você saiba o que procurar, error tracking é proativo - você sabe que existe um problema antes que qualquer usuário reporte.

Stack traces e contexto - o que um bom error tracker captura

Um stack trace isolado frequentemente é insuficiente para reproduzir e corrigir um bug em produção. Ferramentas de error tracking enriquecidas capturam junto com cada erro: a URL ou rota onde ocorreu, os parâmetros da requisição, os headers HTTP relevantes, o sistema operacional e versão do browser do usuário, a versão da aplicação deployada, e variáveis locais no momento do crash. Contexto de usuário - ID, email, plano e dados de perfil - é fundamental para priorizar: um erro que afeta apenas usuários do plano gratuito tem urgência diferente de um que afeta usuários enterprise. Eventos customizados podem ser adicionados manualmente para registrar ações específicas de negócio, como "usuário iniciou checkout" ou "pagamento processado", enriquecendo o contexto de como se chegou ao erro.

Agrupamento de erros - deduplicação inteligente

O maior desafio técnico de error tracking é decidir quando dois erros são a mesma ocorrência ou ocorrências distintas que devem ser investigadas separadamente. Ferramentas modernas usam fingerprinting baseado na estrutura do stack trace - normalizando endereços de memória, versões de biblioteca e IDs dinâmicos - para agrupar erros da mesma origem mesmo que os valores específicos variem entre ocorrências. Um NullPointerException na mesma linha de código chamado por 10.000 usuários diferentes deve gerar um único issue, não 10.000. Agrupamento incorreto - seja muito agressivo, fundindo erros distintos, ou muito granular, criando duplicatas - é um dos maiores motivos de frustração com error trackers e requer tuning de regras de fingerprinting customizadas para cada aplicação.

Breadcrumbs - o caminho que levou ao erro

Breadcrumbs são um registro cronológico de eventos que ocorreram antes do erro, formando um trail que revela o contexto de navegação e interação do usuário antes da falha. Um breadcrumb típico registra: cliques em elementos, navegações de rota, chamadas HTTP feitas pelo frontend, queries ao banco de dados, logs customizados da aplicação e mudanças de estado relevantes. Em aplicações frontend, o SDK de error tracking intercepta eventos do DOM e XMLHttpRequest/fetch automaticamente para criar breadcrumbs sem código adicional. Em aplicações backend, chamadas a serviços externos, queries ao banco e operações de arquivo são capturadas automaticamente pela instrumentação. Ver os 20-30 eventos antes de um crash frequentemente torna o bug imediatamente compreensível, eliminando horas de tentativa e erro para reproduzir o problema.

User impact - quantos usuários foram afetados

A métrica de usuários afetados é o fator mais importante para priorizar qual erro corrigir primeiro, especialmente quando existem dezenas de issues abertos simultaneamente. Um erro que ocorre 1.000 vezes mas para o mesmo usuário repetidamente tem urgência menor que um erro que ocorre 100 vezes mas para 100 usuários diferentes, potencialmente bloqueando uma funcionalidade crítica para eles. Error trackers calculam impacto de usuário correlacionando cada evento de erro com o ID do usuário autenticado - ou um identificador anônimo para usuários não autenticados - e exibem o percentil da base de usuários afetada. Para times com SLAs, monitorar o percentual da base afetada por erros críticos é uma métrica direta de qualidade de serviço que pode ser incluída em dashboards de SLO.

Source maps - rastreando erros em código minificado

Aplicações frontend em produção usam JavaScript e CSS minificados e agrupados, onde stack traces apontam para nomes de variáveis de uma letra e números de linha inúteis como "bundle.js:1:89432". Source maps são arquivos que mapeiam o código minificado de volta ao código fonte original, permitindo que o error tracker exiba stack traces com os nomes de arquivo, função e linha exatos do código que o desenvolvedor escreveu. O upload de source maps deve ser feito como parte do pipeline de CI/CD, associando cada build a seus source maps correspondentes - error trackers como Sentry recebem source maps via API durante o deploy. Por segurança, source maps não devem ser servidos publicamente junto com a aplicação, pois expõem o código fonte; devem ser enviados apenas para o servidor privado de error tracking.

Alertas e notificações de erros novos

O valor crítico do error tracking está na capacidade de notificar imediatamente quando um novo tipo de erro aparece em produção, especialmente após um deploy. Ferramentas de error tracking suportam alertas configuráveis: notificar quando um issue é visto pela primeira vez, quando a taxa de ocorrência de um issue existente aumenta acima de um threshold, quando um issue resolvido volta a ocorrer (regression), ou quando um issue atinge um número mínimo de usuários afetados. Integrações com Slack, PagerDuty, Jira e GitHub Issues permitem que alertas criados pelo error tracker disparem workflows automáticos de triagem. A associação entre deploy e aumento de erros - "este issue apareceu 2 minutos após o deploy da versão 2.3.1" - é um sinal valioso para decisões rápidas de rollback.

Integrações - GitHub, Jira, Slack

Error trackers modernos integram com o stack de desenvolvimento para reduzir o atrito entre detecção e correção. A integração com GitHub cria automaticamente issues no repositório quando novos erros são detectados, e vincula Pull Requests a issues de erro - quando um PR é mergeado, o issue de erro é marcado como resolvido na próxima release. A integração com Jira cria tickets no backlog automaticamente com o contexto completo do erro, incluindo stack trace, frequência e usuários afetados. Integrações com Slack enviam notificações em canais específicos por severidade, com links diretos para o issue e botões de ação - ignorar, atribuir, criar ticket. Webhooks genéricos permitem integração com qualquer sistema interno de workflow, como sistemas de on-call ou plataformas de incidentes como PagerDuty e Opsgenie.

Sampling em error tracking

Em aplicações de alto tráfego, armazenar cada ocorrência de cada erro pode ser impraticável e custoso - um bug em um endpoint popular pode gerar milhões de eventos idênticos em horas. Sampling em error tracking define uma taxa de captura por tipo de issue: os primeiros 100 eventos de um issue novo são sempre capturados para garantir contexto suficiente, e ocorrências subsequentes são amostradas em 1-10% dependendo do volume. O agrupamento e as métricas de frequência continuam precisos mesmo com sampling, pois o error tracker extrapola o volume real a partir da amostra. Erros únicos - que ocorreram apenas uma vez - são sempre capturados integralmente, pois podem indicar problemas raros mas críticos. A configuração de sampling deve ser revisada periodicamente à medida que o tráfego da aplicação cresce.

Conclusão

Error tracking é uma das primeiras ferramentas que qualquer aplicação em produção deveria ter, pois transforma erros silenciosos em notificações acionáveis com contexto suficiente para reprodicção e correção rápida. A combinação de agrupamento inteligente, breadcrumbs, user impact e integrações com ferramentas de desenvolvimento reduz drasticamente o tempo entre a introdução de um bug e sua detecção. Source maps eliminam o problema de stack traces ilegíveis de código minificado. Sampling garante que o sistema funcione eficientemente em alta escala sem perder cobertura de erros críticos. Detectar e corrigir erros antes que usuários reclamem é a diferença entre uma equipe reativa que apaga incêndios e uma equipe proativa que mantém qualidade em produção. Continue em: Fundamentos obrigatórios antes de produção.

Vídeos — Error Tracking

Error Tracking em Produção

Sentry do Zero — Setup Completo

Monitoramento de Erros Frontend e Backend