Log levels são rótulos de severidade anexados a cada entrada de log. Eles controlam o que é registrado, o que é exibido e o que dispara alerta. O padrão dominante define cinco níveis — DEBUG, INFO, WARN, ERROR, FATAL — em ordem crescente de severidade. O valor central do sistema de níveis: manter o ruído no mínimo em operação normal e, quando algo quebra, filtrar e alertar rápido por nível.
Referência rápida: os cinco níveis padrão
| Nível |
Significado |
Conteúdo típico |
Produção |
Dispara alerta |
| DEBUG |
Detalhe de depuração |
Valores de variáveis, statements SQL, argumentos de função |
Desligado |
Não |
| INFO |
Marcos normais do negócio |
Login do usuário, pedido criado, tarefa iniciada |
Ligado |
Não |
| WARN |
Anormal, mas o sistema se recuperou sozinho |
Retry bem-sucedido, fallback acionado, requisição lenta |
Ligado |
Agregar e revisar manualmente |
| ERROR |
A operação atual falhou |
API 5xx, pagamento recusado, ponteiro nulo |
Ligado |
Sim |
| FATAL |
Indisponibilidade em nível de sistema |
Banco inalcançável, serviço não sobe |
Ligado |
Sim (resposta P0) |
Como decidir o nível certo
Na prática, usar mal os níveis é mais comum do que faltar log. Critérios aplicáveis:
DEBUG: para os olhos do próprio desenvolvedor
- Critério: essa informação não vale nada enquanto o sistema funciona normalmente e só serve para investigar um bug específico;
- Conteúdo típico: argumentos e retornos de funções, resultados intermediários, acertos de cache;
- Princípio-chave: desligado por padrão em produção. Não apagado — filtrado, para poder ligar pontualmente quando aparecer problema.
INFO: para quem pergunta "o que o sistema está fazendo"
- Critério: reler essa entrada seis meses depois permite reconstruir a jornada do usuário;
- Conteúdo típico: ações-chave do negócio (cadastro, compra, publicação), início/fim e duração de tarefas;
- Antipadrão: logar todo HTTP 200 como INFO — isso é trabalho do access log; não polua o log de negócio com isso.
WARN: algo deu errado, mas o sistema segurou a onda
- Critério: alguém deveria saber, mas ninguém precisa se levantar às 3 da manhã;
- Conteúdo típico: sucesso após retry, rate limit/degradação acionada, duração de requisição acima do limite;
- Sinal de risco: uma disparada de WARN costuma anteceder os ERROR — ligue a uma monitoração de tendência.
ERROR: a ação de um usuário falhou
- Critério: se não for consertado, o usuário vai bater no mesmo problema de novo;
- Conteúdo típico: chamada a serviço externo falhou, exceção de validação, erro não capturado;
- Exigência-chave: todo ERROR precisa vir com contexto (URL, ID de usuário/tenant, parâmetros da requisição, stack trace), senão é só ruído sem ação possível.
FATAL: o sistema já está fora do ar
- Critério: o serviço como um todo não consegue mais funcionar;
- Conteúdo típico: falha de conexão com o banco, configuração obrigatória ausente, falha na inicialização;
- Dica prática: FATAL é raro em aplicações web — a maioria dos "caiu tudo" aparece como uma rajada de ERROR, coberta por um alerta de "pico súbito de ERROR". Não abuse do FATAL, você dilui a severidade dele.
Log levels no Console do navegador
Os níveis do front têm os mesmos nomes do back, mas fazem menos. O Console suporta nativamente:
| Método |
Nível no Console |
Uso |
console.debug() |
Debug (oculto por padrão; ative Verbose) |
Depuração em desenvolvimento |
console.log() |
Info |
Saída geral |
console.info() |
Info |
Igual ao de cima, mais explícito |
console.warn() |
Warning, amarelo |
Avisos de problemas recuperáveis |
console.error() |
Error, vermelho, com stack trace |
Falhas e exceções não capturadas |
Duas dicas práticas:
Escreva a depuração do front com console.debug em vez de console.log — o build de produção a esconde atrás do filtro padrão, sem limpeza manual;
Exceções não capturadas (window.onerror / unhandledrejection) já são nível ERROR por padrão e são a primeira pista em produção.
O problema especial do front: o usuário não coleta logs por você
Os logs do back ficam nos servidores, prontos para consulta quando aparece problema. Os do front se espalham pelo navegador de cada usuário — o usuário reporta "a página quebrou", e os erros de Console e as requisições falhas somem junto com aquela sessão. Quando o usuário segue um tutorial para abrir o DevTools (passos em como abrir o console do navegador), um refresh já levou os erros embora.
A pergunta que uma estratégia de log de front precisa responder não é "como distribuir os níveis", e sim "como preservar os logs do instante exato da falha". Abordagens comuns:
| Abordagem |
Como funciona |
Custo |
| Reporter próprio |
Mandar toda a saída do console de volta ao servidor |
Custo alto de armazenamento/privacidade; sampling difícil de ajustar |
| Plataforma de monitoração front |
Captura completa + replay de sessão |
Cobrança por volume; caro para times pequenos e médios |
| Captura sob demanda (anexada ao relatório de bug) |
Ao enviar o feedback, os erros Console/Network daquele momento são anexados automaticamente |
Custo mínimo; cobre "reportado pelo usuário", a maior fonte de todas |
A terceira abordagem casa naturalmente com o relatório de bug: o momento em que o usuário reporta o bug é exatamente o momento em que os logs importam.
O BugCapturer faz exatamente essa captura sob demanda: quando um usuário (mesmo totalmente leigo) envia uma captura/gravação anotada pela extensão ou pelo SDK embutido, o relatório leva automaticamente os erros de Console daquele momento (com stack traces de ERROR) e as requisições Network que falharam, além da URL e do ambiente do navegador (veja a função de diagnóstico). O relatório chega ao desenvolvedor com o contexto de log ERROR já anexado — chega de "abre o F12 e copia". Os relatórios podem ser compartilhados por um link sem login, ou enviados automaticamente a um canal do Slack / Microsoft Teams para acompanhamento centralizado.
Erros comuns
| Erro |
Prática certa |
Tudo com console.log, nunca limpa |
Usar níveis: debug para depurar, info para marcos de negócio, tirar o debug no build |
| Logar falha como INFO "para não assustar o ops" |
Falha é ERROR; o alerta depende dos níveis, não de alguém lendo logs |
| ERROR só com mensagem, sem contexto |
Anexar sempre URL, parâmetros e stack — senão você não registrou nada |
| DEBUG ligado em tudo "pra facilitar investigar" |
Níveis são um filtro: DEBUG desligado no dia a dia, ligado sob demanda quando surge o problema |
| WARN se acumulando sem tratamento |
Levar os WARN a alertas de tendência; uma rajada anuncia os ERROR |
FAQ
P: Quantos log levels existem?
R: O padrão dominante tem cinco — DEBUG, INFO, WARN, ERROR, FATAL. Alguns frameworks (Syslog, sistemas tipo Trace) têm variantes TRACE/NOTICE/CRITICAL, mas a semântica corresponde um a um à tabela acima.
P: Como escolher e configurar os logging levels?
R: Tudo ligado no desenvolvimento (a partir de DEBUG), a partir de INFO ou WARN na produção; ERROR dispara alerta, WARN alimenta a monitoração de tendência. Configure as bibliotecas separadas do código de negócio para que o DEBUG de uma dependência não inunde tudo.
P: O front precisa de níveis de log como o back?
R: Precisa, mas simplificado: quatro níveis — debug / info / warn / error — bastam. O importante é ERROR com stack trace e resolver o problema de "preservar os logs do instante da falha".
P: Como conseguir que o usuário me mande os erros de Console ao reportar um bug?
R: Pedir para usuário leigo copiar erros é causa perdida. Use uma ferramenta como o BugCapturer, que captura os erros Console/Network automaticamente ao enviar — veja a seção de "captura sob demanda" acima.