Como monitorar seu app e saber quando ele quebra

Seu app quebrou às 3h da manhã. Uma rota parou de responder. Cinquenta usuários tentaram usar e desistiram. Você só descobriu ao meio-dia, quando um cliente mandou mensagem irritado.

Isso é o que acontece sem monitoramento. Você fica cego. O erro existe, mas ninguém te avisa.

Meu take: você quer ser o primeiro a saber que quebrou. Não o último. Monitoramento é o que troca "o cliente me avisou" por "eu já estava consertando".

Os três pilares

Monitorar não é uma coisa só. São três, que trabalham juntas:

• Captura de erro: registra toda exceção que acontece, com contexto.
• Logs: o diário do app, o que aconteceu e quando.
• Alertas: o aviso que chega até você quando algo dá errado.

Sem captura, você não sabe o que quebrou. Sem log, não sabe por quê. Sem alerta, não sabe que quebrou. Precisa dos três.

Passo 1: capture os erros

Ferramentas como Sentry fazem isso pronto. Você instala, e toda exceção não tratada é registrada com stack trace, navegador, usuário afetado.

npm install @sentry/node

import * as Sentry from "@sentry/node"

Sentry.init({ dsn: "sua-dsn-aqui" })

A partir daí, erro que estoura vira um registro com contexto. Você abre o painel e vê exatamente onde, quando e pra quem quebrou. Sem isso, você fica adivinhando.

Passo 2: logue o que importa

Log não é encher o console de mensagem. É registrar os momentos-chave: requisição recebida, operação importante concluída, erro tratado.

Use níveis:

logger.info("Usuário 42 iniciou pagamento")
logger.warn("Tentativa de login falhou para IP 1.2.3.4")
logger.error("Falha ao processar pagamento", { userId: 42, erro })

Regra de ouro: nunca logue senha, token ou dado sensível. Log vaza. Se você logou o cartão do cliente, você criou um problema de LGPD.

Log bom responde a pergunta "o que estava acontecendo quando quebrou?". Sem detalhe demais, sem detalhe de menos.

Passo 3: configure alertas

Log você lê depois. Alerta te acorda agora. Configure avisos pros eventos críticos:

• Taxa de erro subiu acima do normal.
• Uma rota importante parou de responder.
• Tempo de resposta explodiu.

O alerta pode chegar por e-mail, Slack, WhatsApp. O canal importa menos que a regra: só alerte no que exige ação. Alerta demais vira ruído e você começa a ignorar. Aí quando o grave chega, passa batido.

Passo 4: monitore se o app está de pé

O básico dos básicos: um serviço que chama seu app de tempos em tempos e avisa se ele não responde. Chamam de uptime monitor.

Ferramentas gratuitas fazem um ping na sua URL a cada minuto. Caiu, você recebe aviso na hora. Configura em cinco minutos, dorme tranquilo.

Passo 5: uma rota de saúde

Crie um endpoint simples que confirma que o essencial funciona:

app.get("/health", async (req, res) => {
  try {
    await db.ping()
    res.status(200).json({ status: "ok" })
  } catch {
    res.status(500).json({ status: "erro" })
  }
})

O monitor bate nessa rota. Se o banco caiu, ela retorna erro, e você sabe que não é só o servidor, é a dependência.

O checklist de monitoramento

1. Captura de erro instalada, com contexto.
2. Logs nos pontos-chave, sem dado sensível.
3. Alertas só no que exige ação.
4. Uptime monitor batendo na URL.
5. Rota de health checando as dependências.

Vibecoding com engenharia é não confiar que vai dar tudo certo. Vai quebrar. A pergunta é se você vai saber antes ou depois do cliente. Monitoramento é essa diferença.

A decisão é sua.