O que é Sentry e para que serve

Sentry é uma plataforma de monitoramento de aplicações focada em captura de erros e performance, usada por mais de 90.000 organizações incluindo GitHub, Cloudflare, Atlassian e Reddit. Fundado em 2012 como projeto open-source para captura de exceções Python, o Sentry evoluiu para cobrir mais de 100 plataformas e linguagens com SDKs nativos, e expandiu seu escopo para incluir monitoramento de performance, session replay, profiling e alertas baseados em SLO. A proposta central do Sentry é ser a ponte entre o momento em que um bug ocorre em produção e o momento em que o desenvolvedor tem contexto suficiente para corrigi-lo sem necessidade de tentar reproduzir manualmente. Um único evento capturado pelo Sentry pode conter stack trace, variáveis locais, breadcrumbs de 30 eventos anteriores, dados do usuário afetado e contexto de release.

SDK — instrumentando aplicações web, mobile e backend

O Sentry fornece SDKs para JavaScript, TypeScript, React, Vue, Angular, Next.js, Python, Django, Flask, FastAPI, Java, Spring Boot, .NET, Go, Ruby on Rails, PHP Laravel, iOS, Android, React Native e Flutter, entre outros. A inicialização básica requer apenas chamar Sentry.init() com o DSN — Data Source Name — gerado pelo projeto no Sentry, e a partir daí todas as exceções não tratadas são capturadas automaticamente. Para backends .NET, o pacote NuGet Sentry.AspNetCore integra com o middleware do ASP.NET Core, capturando exceções com contexto da requisição HTTP incluindo route, query parameters e body sanitizado. O SDK é configurável para filtrar erros esperados, adicionar contexto customizado via Sentry.setTag, Sentry.setUser e Sentry.addBreadcrumb, e controlar a taxa de sampling por ambiente.

Issues — agrupamento e triagem de erros

A interface de issues do Sentry organiza erros capturados em issues agrupados pelo fingerprint do stack trace, com métricas de frequência, usuários afetados, primeira e última ocorrência, e a versão da aplicação onde o erro foi introduzido. Workflows de triagem permitem atribuir issues a desenvolvedores, marcá-los como resolvidos em uma versão específica, ignorar com condições de reativação ou marcar como regressão quando o mesmo problema volta após ter sido resolvido. A integração com releases do Sentry — criadas via CLI ou CI/CD — associa cada issue ao commit exato que o introduziu usando suspect commits, que analisa automaticamente os commits da release afetada para identificar o mais provável causador. Isso elimina o trabalho manual de bisect em Git para encontrar quando um bug foi introduzido.

Performance — rastreando transações lentas

O módulo de performance do Sentry monitora transações — requisições HTTP completas — medindo latência de endpoints, identificando os mais lentos por percentil p50/p75/p95/p99, e detectando regressões de performance entre releases. Cada transação é decomposta em spans que mostram o tempo gasto em: operações de banco de dados com a query SQL executada, chamadas HTTP externas, operações de cache e código da aplicação. O Sentry detecta automaticamente problemas comuns como N+1 queries — múltiplas queries idênticas executadas em loop — e queries lentas sem índice, apresentando-os como insights acionáveis na interface. A correlação entre um evento de erro e a transação que o contém é direta: de um issue de erro, é possível navegar para os traces de performance da mesma requisição.

Session Replay — ver o que o usuário fez antes do erro

Session Replay é uma funcionalidade do Sentry que captura uma reprodução da sessão do usuário — como um vídeo do que aconteceu na tela — usando reconstrução DOM em vez de vídeo real, o que garante privacidade e tamanho compacto. Quando um erro ocorre, o replay dos 60 segundos anteriores é automaticamente vinculado ao issue, permitindo que o desenvolvedor veja exatamente o que o usuário estava fazendo antes da falha: quais elementos clicou, o que digitou, como a interface estava renderizada e quais requisições de rede ocorreram. Elementos de entrada como campos de senha e dados sensíveis são mascarados automaticamente pelo SDK antes de serem capturados. Session Replay elimina a necessidade de reproduzir manualmente cenários de erro complexos que dependem de estado de UI específico.

Releases e deploy tracking

O Sentry integra com pipelines de CI/CD via CLI ou GitHub Actions para criar releases associadas a commits e uploads de source maps. Quando uma nova release é deployada, o Sentry compara automaticamente as métricas de erro da release atual com a anterior, identificando se o deploy introduziu novos issues ou aumentou a frequência de issues existentes. Alertas de release health monitoram a taxa de sessions sem crash e a adoção da release — percentual de usuários na nova versão — ajudando a decidir se um rollback é necessário. O fluxo de "resolve in version" permite que desenvolvedores marquem um issue como resolvido em uma versão específica, e o Sentry automaticamente reativa o issue se ele aparecer novamente em versões posteriores, criando um histórico de regressões rastreável.

Alertas e notificações

O sistema de alertas do Sentry suporta dois tipos principais: issue alerts para eventos específicos — novo issue, issue resolvido que voltou, issue ultrapassou threshold de ocorrências — e metric alerts baseados em agregações como taxa de erros, Apdex score ou p95 de latência ultrapassando um valor em um período de tempo. Regras de alerta são configuráveis por projeto, ambiente e tipo de transação, permitindo alertas de alta sensibilidade para endpoints críticos e baixa sensibilidade para endpoints menos importantes. Integrações nativas com Slack, PagerDuty, Jira, GitHub e Linear garantem que alertas sejam entregues no canal certo e criem tickets ou incidents automaticamente. A fila de alertas respeita silences configurados para janelas de manutenção e deploys planejados.

Data scrubbing — privacidade e LGPD

Dados de usuário capturados pelo Sentry — endereços de email, IPs, tokens de sessão, dados de formulário — devem ser tratados com cuidado para conformidade com LGPD, GDPR e regulamentos similares. O Sentry oferece data scrubbing configurável que remove automaticamente campos com nomes sensíveis como password, credit_card, ssn e token antes de armazenar eventos. Scrubbing customizado via expressões regulares permite remover dados específicos do domínio da aplicação. A funcionalidade de PII scrubbing aplica anonimização nos campos de usuário capturados automaticamente pelo SDK. Para conformidade máxima, o Sentry pode ser configurado para não capturar IPs de usuário, não armazenar dados de usuário não autenticado, e purgar eventos após períodos configuráveis. Self-hosting do Sentry elimina completamente a questão de dados sair da infraestrutura controlada.

Sentry self-hosted vs cloud

O Sentry open-source pode ser auto-hospedado via Docker Compose em um servidor dedicado — a configuração mínima recomendada é 4 CPUs e 16 GB de RAM para instâncias de médio porte. Self-hosting oferece controle total sobre os dados, sem limites de volume de eventos além da capacidade do servidor, e custo fixo independente do volume de erros. O Sentry Cloud (sentry.io) tem tier gratuito com 5.000 erros por mês e planos pagos baseados em volume, com a vantagem de zero operação de infraestrutura, atualizações automáticas e maior disponibilidade. Para empresas com requisitos de compliance como LGPD que proíbem dados de usuário em servidores externos, ou com volume muito alto que tornaria o cloud proibitivamente caro, self-hosted é a escolha natural. O processo de migração entre self-hosted e cloud é suportado via export/import de dados.

Conclusão

Sentry é a ferramenta mais completa do mercado para monitoramento de erros e performance em aplicações reais, cobrindo desde a captura automatizada de exceções até session replay, profiling e rastreamento de releases. A integração com fluxos de CI/CD e ferramentas de desenvolvimento como GitHub e Jira fecha o ciclo entre detecção e correção sem necessidade de processos manuais. Data scrubbing e conformidade com LGPD/GDPR tornam o Sentry adequado para aplicações que lidam com dados de usuário sensíveis. A opção de self-hosting garante controle total para requisitos de compliance rigorosos. Para qualquer aplicação em produção com usuários reais, o Sentry — ou um equivalente — é uma das primeiras camadas de observabilidade que deveria ser instalada. Continue em: Fundamentos obrigatórios antes de produção.

Vídeos — Sentry e Error Tracking

Conceitos — Sentry

DSN

Data Source Name — identificador único do projeto Sentry para o SDK

Session Replay

Reprodução DOM da sessão do usuário antes do erro, com mascaramento de dados sensíveis

Suspect Commits

Análise automática dos commits da release para identificar o causador do bug

N+1 Detection

Detecção automática de queries repetidas em loop em transações de performance

Data Scrubbing

Remoção automática de campos sensíveis antes de armazenar eventos

Posts — Error Tracking e Performance

@bytebytego

Reels — Sistemas e Arquitetura

@bytebytego

ByteByteGo no Facebook

Tweets — Qualidade em Produção

@mjovanovictech

Como testar que sua API é resiliente e segura para produção real

Ver post completo no X →
@mjovanovictech

Implementando padrões de resiliência em .NET Core com exemplos reais

Ver post completo no X →
@mjovanovictech

Vertical Slice Architecture — organizando sistemas para escala

Ver post completo no X →
@mjovanovictech

5 anos com Clean Architecture — lições de sistemas em produção

Ver post completo no X →
@mjovanovictech

Design de APIs resilientes — retry, backoff e idempotência juntos

Ver post completo no X →
@mjovanovictech

Monolito vs Microsserviços — como escolher para cada contexto

Ver post completo no X →

O que dizem

Henrique B. ★★★★★

Session Replay mostrou o estado exato da UI antes do crash. Reprodução de 5 minutos virou 2.

Isabella C. ★★★★★

Suspect commits apontou exatamente o PR que introduziu a regressão de performance.

Rodrigo F. ★★★★★

Self-hosted resolveu nosso compliance. Dados de usuário nunca saem da nossa infraestrutura.