Noções básicas de monitoramento para fundadores: métricas e alertas para começar

O que é monitoramento (e por que fundadores se sentem às cegas sem ele)

Monitoramento é como você descobre que seu app está doente antes dos usuários te avisarem. São os sinais e alertas que respondem a uma pergunta rápido: o produto está funcionando agora para pessoas reais?

Fundadores se sentem às cegas porque a maioria das quebras não parece uma queda total. O site carrega, mas o login falha. Pagamentos dão timeout para uma parcela dos usuários. Um job em background para de enviar e-mails. Sem monitoramento, você fica sabendo por mensagens raivosas, receita perdida ou um colega dizendo “Algo está lento”.

O objetivo não é um dashboard perfeito. O objetivo é aviso precoce. Bom monitoramento é silencioso em dias bons e barulhento em dias ruins.

No mínimo, você quer saber:

• Usuários estão sendo bloqueados (e quantos)
• Onde está falhando (qual página, endpoint ou job)
• Quando começou (timestamp claro e tendência)
• Quem precisa agir (um alerta que alcance a pessoa certa)

Se você só tirar uma coisa do monitoramento, que seja esta: você pode responder “Está quebrado agora, e está piorando?” em menos de um minuto.

Comece pequeno, depois melhore toda semana. Adicione uma métrica, um alerta ou um detalhe de log por vez. Se você herdou uma base de código gerada por IA, isso importa ainda mais. Um app pode “funcionar” numa demo enquanto esconde problemas como fluxos de autenticação quebrados, segredos expostos ou jobs em background que falham silenciosamente.

Conjunto inicial: quatro sinais que pegam a maioria das quebras

A maioria dos incidentes em produção aparece como um de quatro problemas: usuários encontram erros, páginas ficam lentas, o app fica inacessível, ou o trabalho em background para de andar.

Um conjunto inicial que cobre esses modos de falha:

• Errors (taxa e tipos de erro mais comuns)
• Latency (quanto tempo pedidos-chave levam)
• Uptime (o app é alcançável de fora da sua rede)
• Queue depth (os jobs em background estão se acumulando?)

Esses quatro cobrem tanto a porta da frente quanto os bastidores. Errors e latency capturam o que usuários sentem agora. Uptime pega quedas totais e falhas óbvias de deploy ou rede. Queue depth pega falhas silenciosas que não aparecem na UI até horas depois.

Mapeado para a dor do usuário:

• Errors: “Não consigo fazer login” ou “Checkout falhou.”
• Latency: “Carrega pra sempre”, mesmo que tecnicamente funcione.
• Uptime: “O site está fora.”
• Queue depth: “Meu relatório nunca chegou” ou “E-mails pararam de enviar.”

Logs e tracing são ótimos para diagnóstico, mas são mais difíceis de usar para alertas quando você está começando. Métricas mais alertas simples geralmente mostram “algo está errado” mais rápido.

Errors: a forma mais rápida de saber que usuários estão bloqueados

Se você só acompanhar uma coisa primeiro, acompanhe erros. Eles são o sinal mais claro de que pessoas reais não conseguem completar uma tarefa.

Comece com dois números:

• Error rate: a porcentagem de requisições que falham
• Error count: quantas falhas aconteceram

A taxa mostra impacto. A contagem mostra volume. Uma taxa pequena pode machucar se o tráfego for alto.

Separe erros em client vs server desde cedo:

• 4xx (erros do cliente) frequentemente significam entrada ruim, sessões expiradas ou rotas que não existem mais.
• 5xx (erros do servidor) geralmente significam que seu sistema falhou: API travou, query quebrada, deploy ruim, misconfig.

Você não precisa de rotulagem perfeita no primeiro dia, mas essa divisão torna a triagem mais rápida.

Alertas devem focar em padrões, não em eventos únicos. Um 500 isolado pode ser ruído. Um pico ou uma taxa sustentada elevada é um incêndio.

Um conjunto prático inicial:

• Pico súbito: a taxa de erro sobe acima do baseline por 5–10 minutos
• Problema sustentado: a taxa de erro permanece acima de um limite por 15–30 minutos
• Foco em 5xx: alerta sobre erros de servidor mesmo se o total de erros for baixo

Adicione um alerta para o “caminho do dinheiro” que mais importa: login, signup ou checkout. Se os 500s no login subirem de 0,1% para 5% após um release, você quer saber antes dos clientes te mandarem e-mail.

Latency: capture lentidões antes que tickets de suporte se acumulem

Latency é quanto tempo um usuário espera depois de clicar, tocar ou atualizar. Mesmo quando seu app está “up”, alta latência parece quebrado. Pessoas abandonam a página, tentam novamente ou assumem que a conta está travada.

Dois números contam a história com clareza:

• p50: a experiência típica
• p95: a experiência “pior comum”

Se p50 está bem mas p95 sobe, a maioria dos usuários está ok, mas uma parte notável está presa esperando. Essas são as pessoas que abrem tickets.

Não monitore todas as rotas no primeiro dia. Segmente latência pelas ações que mais importam para o negócio. Uma página de configurações lenta é irritante. Um login lento trava o crescimento.

Pontos de partida comuns:

• Login e signup
• Checkout ou confirmação de pagamento
• Busca e páginas de resultados
• Qualquer ação de “criar” (novo pedido, novo ticket, novo post)

Alertas funcionam melhor quando detectam mudança, não um minuto ruim. Uma regra simples: alerte quando p95 subir bem acima do normal, ou permanecer alto tempo suficiente para que usuários sintam.

Um conjunto inicial útil:

• p95 de latência é 2x o baseline por 10 minutos
• p95 excede um limite rígido (por exemplo: 2–3 segundos) por 5–10 minutos
• p50 sobe continuamente por 15 minutos (muitas vezes questão de capacidade ou banco)
• p95 dispara só em um endpoint (muitas vezes caminho de código ou API externa)

Exemplo: a homepage continua rápida, mas p95 do endpoint de login sobe de 400ms para 4s após um deploy. Você pode não notar num teste rápido, mas novos usuários vão.

Uptime: confirme que o app é alcançável de fora

Uptime responde uma pergunta: um usuário real consegue alcançar seu app agora? Ele pega quedas totais, DNS ruim, SSL expirado ou um deploy que não voltou.

Uptime não significa que seu produto funciona. Você pode retornar 200 OK enquanto login está quebrado, pagamentos falham ou a página está em branco porque um script caiu. Trate uptime como o alarme de fumaça, não como a investigação.

Use uma checagem externa que rode fora da sua infraestrutura, do mesmo jeito que os clientes se conectam. Pode bater na homepage, num endpoint de health leve, ou numa rota de ping que confirme que o servidor responde rápido.

Para evitar ruído, alerte em falhas consecutivas, não por um único blip.

Configuração inicial:

• Cheque a cada 1 a 5 minutos de pelo menos 2 locais
• Dispare alerta após 2 a 3 falhas consecutivas
• Notifique uma pessoa primeiro (push ou SMS), depois escale se não houver reconhecimento
• Inclua na notificação a URL que falhou, o código de status e o tempo de resposta

Planeje janelas de downtime programado também. Pause alertas ou marque a janela para não entrar em pânico por falhas esperadas.

Exemplo: você envia um hotfix numa sexta à tarde e a configuração do reverse proxy está errada. O app está “rodando”, mas nada é alcançável publicamente. Uma checagem externa de uptime pega isso em minutos.

Queue depth: detecte jobs em background que estão travados silenciosamente

Algumas das falhas mais dolorosas não aparecem como um erro claro. Aparecem como trabalho se acumulando em background: e-mails de reset de senha, importação de arquivos, webhooks de pagamento, jobs de processamento, relatórios noturnos. A UI parece bem enquanto clientes esperam horas.

Queue depth é quanto trabalho está esperando para ser processado. Monitore também a idade do job (há quanto tempo o job mais antigo está esperando). Profundidade mostra volume. Idade mostra impacto no usuário.

O que monitorar

Mantenha pequeno e visível:

• Tamanho da fila (jobs pendentes)
• Idade do job mais antigo (tempo desde que foi enfileirado)
• Taxa de processamento (jobs finalizados por minuto), se disponível

Alertas que pegam problemas cedo

Comece com thresholds que você pode refinar depois:

• Tamanho da fila permanece acima de 100 por 10 minutos
• Idade do job mais antigo excede 5 minutos (aviso) ou 15 minutos (urgente)
• Tamanho da fila sobe por 15 minutos enquanto o tráfego está normal

Se você roda múltiplas filas (e-mails vs imports), alerte por fila. Um worker travado não deve ficar escondido atrás de outra fila saudável.

Quando profundidade ou idade disparam, a causa costuma ser: um processo worker está down, um loop de retry está re-adicionando o mesmo job falho, ou uma dependência está lenta (provedor de e-mail, banco, API externa).

Exemplo: “e-mails pararam de enviar.” Uptime parece ok. Mas a idade da fila salta para 40 minutos porque o worker caiu após um deploy. Um alerta de idade de fila pegaria isso antes dos clientes perguntarem onde está o link de reset.

Como configurar seus primeiros alertas em 60 minutos (passo a passo)

Você não precisa de uma configuração complexa no primeiro dia. O ganho mais rápido é um pequeno conjunto de alertas ligado ao que clientes realmente fazem.

Passo 1: Anote as ações que te dão dinheiro

Escolha 3 a 5 ações centrais. Se qualquer uma delas quebrar, usuários ficam presos rápido.

• Sign up
• Log in
• Iniciar checkout ou pagar
• Criar o objeto principal do seu app (projeto, pedido, post)
• Exportar, convidar, ou compartilhar

Passo 2: Adicione uma métrica e um alerta por ação

Mantenha mínimo: uma métrica que diz se a ação está falhando e um alerta que você realmente verá.

• Para signup e login: alerte na taxa de erro (ou requisições falhas) em uma janela curta.
• Para pagamentos: alerte em picos de 4xx e 5xx e em latência (pagamentos lentos costumam falhar silenciosamente).
• Para criar/exportar: alerte em falhas de jobs de background ou saúde da fila se for assíncrono.

Passo 3: Defina thresholds com base no comportamento normal

Use os últimos dias de comportamento normal. Se erros de login costumam ficar perto de zero, um limite como “mais de 5 falhas em 5 minutos” pega problemas reais sem barulho constante. Para latência, comece com “2x mais lento que o normal” em vez de caçar um número perfeito.

Passo 4: Envie alertas para onde você realmente verá

Um alerta que fica só no dashboard não é um alerta. Roteie para chat da equipe, notificações no telefone ou o que você checa durante o dia.

Passo 5: Revise semanalmente e ajuste

Uma vez por semana, veja o que disparou.

• Se um alerta é ruidoso, aumente o threshold ou adicione condição de duração (só alertar se durar 10 minutos).
• Se você perdeu um incidente, abaixe o threshold ou adicione um alerta específico para o fluxo.

Erros comuns que tornam o monitoramento inútil

A forma mais rápida de desperdiçar monitoramento é tratá-lo como um checkbox. Monitoramento é menos sobre dashboards bonitos e mais sobre obter alguns sinais claros que levem à ação.

Fadiga de alertas

Se seu telefone vibra para todo pico pequeno, você vai começar a ignorar tudo. Defina thresholds para que alertas signifiquem “alguém provavelmente está bloqueado” ou “isso ficará visível para o usuário em breve”, não “um gráfico se mexeu”.

Só monitorar uptime

Seu app pode estar “up” enquanto o fluxo mais importante está quebrado (login, checkout, reset de senha). Se você só tem um ping de uptime, vai achar que está tudo bem enquanto clientes veem um botão girando.

Alertas sem próximo passo

Alertas devem apontar para a próxima ação, não só um número assustador.

• Atribua um dono para cada alerta (mesmo que seja “on-call esta semana”).
• Inclua contexto: endpoint, janela de tempo, quão ruim está.
• Adicione contexto de deploy: “novo release há 12 minutos” muda como você responde.
• Tenha um playbook de uma linha: “Se 500s subirem, reverter e checar logs de auth.”

Olhar só para o tamanho da fila e ignorar a idade

Uma fila pequena ainda pode estar quebrada se o job mais antigo está esperando 20 minutos. Tamanho mostra volume. Idade mostra se o trabalho está andando.

Exemplo: seu worker perde acesso ao banco após uma mudança de credenciais. O comprimento da fila fica estável porque jobs falham rápido e re-enfileiram, mas a idade sobe e usuários veem “relatório será enviado por e-mail” para sempre. Se você alertar por idade (e retries), pega isso cedo.

Checklist rápido: você está coberto para o próximo incidente?

Se não fizer mais nada esta semana, certifique-se de que pode responder rápido: “Usuários estão bloqueados agora?”

Escolha metas que cabem no seu app hoje, depois ajuste.

• Errors: Um alerta para 5xx sustentado e um limite claro de “isso é ruim” no fluxo principal (por exemplo, >1% por 5 minutos).
• Latency: p95 para 2–3 endpoints chave (login, checkout, busca ou sua API principal), com um alvo que usuários toleram (por exemplo, p95 >1.5s por 10 minutos).
• Uptime: Uma checagem externa que alerte só após falhas consecutivas (por exemplo, 3 falhas seguidas).
• Queue health: Visibilidade se os jobs estão sendo processados. Alerta em idade do job mais antigo e em profundidade subindo tempo suficiente para mostrar que você está ficando para trás.
• Pessoas/processo: Uma pessoa responsável quando um alerta dispara, com um caminho de escalonamento simples.

Um teste rápido: peça a um amigo usar seu app do celular e tentar a ação principal. Se falhar, seus alertas te dizem em 5 minutos? Você saberia se é erro, lentidão, acessibilidade ou jobs travados?

Exemplo: pegar um login quebrado antes do cliente reportar

Você faz uma pequena mudança numa sexta à tarde: um ajuste nas telas de signup e login. Parece ok no seu teste rápido. Mas para alguns usuários, o login falha mesmo com a senha correta.

Em minutos, dois sinais se movem de forma difícil de ignorar:

• Errors disparam no endpoint de auth.
• Latency sobe ao mesmo tempo, porque o backend tenta novamente uma chamada ao banco (ou a um serviço externo) antes de falhar.

Se seus alertas incluem janelas de tempo e contexto de deploy, você alinha isso com seu release e decide rápido.

Uma resposta limpa:

• Reverter o último deploy
• Confirmar que os erros voltam ao normal
• Reenviar com uma correção segura quando houver tempo

Depois, você adiciona dois alertas direcionados para o fluxo de login:

• Alerta quando a taxa de erro do endpoint de login cruzar um pequeno limite por 5 minutos.
• Alerta separada quando a latência dele subir em relação ao baseline.

Isso também é onde código gerado por IA pode atrasar você. Pode haver uma chamada de login que passa por três helpers de auth diferentes, um middleware copiado e um loop de retry pela metade. Os sintomas aparecem como erro e lentidão, enquanto a causa real está enterrada no fluxo de controle confuso.

Próximos passos: mantenha pequeno, depois resolva as causas raízes

Comece com um conjunto mínimo de sinais, depois deixe incidentes reais te dizerem o que adicionar. O objetivo não é “cobertura perfeita.” É notar quebras cedo e ter uma ação clara.

Comece com os quatro sinais (errors, latency, uptime, queue depth). Rode por uma ou duas semanas. Quando algo quebrar, resista à tentação de adicionar cinco novos alertas. Anote o que aconteceu e o que teria deixado óbvio mais cedo.

Uma nota curta de incidente é suficiente:

• O que os usuários viram e quando começou
• O que mudou antes da quebra (deploy, config, outage de terceiro)
• O conserto que você aplicou (ou rollback)
• Uma etapa de prevenção (teste, guarda, ajuste de alerta, log que faltou)

Adicione um novo alerta só quando puder responder: “Se isso disparar, quem faz o quê nos próximos 10 minutos?” Se a ação for “investigar depois”, isso pertence a um dashboard, não a um pager.

Quando alertas continuam apontando para as mesmas falhas (login quebrando após pequenas mudanças, segredos vazando em logs, jobs acumulando toda noite), isso costuma ser problema de base de código, não de monitoramento. Se você herdou um app gerado por IA de ferramentas como Lovable, Bolt, v0, Cursor ou Replit e ele continua se comportando diferente em produção do que em demos, uma auditoria focada pode economizar muito tempo. FixMyMess (fixmymess.ai) faz diagnóstico e reparo de base de código exatamente para essa situação, incluindo hardening de segurança e preparação para deploy.