Alertas de interrupção: 3 verificações simples para detectar falhas precoces

Por que essas três verificações pegam a maioria das interrupções precoces

A maioria das interrupções é descoberta primeiro pelos clientes, não pela sua equipe. Alguém tenta carregar seu site, não consegue se cadastrar, ou paga e nunca recebe acesso. Quando chegam os e-mails do suporte ou alguém nota a queda de receita, você já está no meio de um incidente.

“Precoce” costuma ser os primeiros 5 a 30 minutos. É quando um problema pequeno ainda é fácil de reverter: reverter um deploy, reiniciar um worker travado, renovar um segredo expirado ou corrigir uma má configuração antes que centenas de usuários sejam afetados.

Por isso, menos alertas relevantes costumam vencer uma lista longa e barulhenta. Se você tem dez monitores disparando o tempo todo, as pessoas param de confiar neles. Um conjunto pequeno de sinais que quase sempre importa chama atenção rápido, mesmo às 2h da manhã.

Essas três verificações cobrem as formas mais comuns de um produto falhar no mundo real:

• Alguém consegue acessar o site?
• Um novo usuário consegue completar o cadastro?
• Dinheiro e eventos de fulfillment fluem (pagamentos e webhooks)?

Juntas, formam uma rede de segurança simples: “porta de entrada, crescimento, receita”. Se qualquer uma falhar, provavelmente você tem uma interrupção sentida pelos usuários.

O que elas não cobrem: desempenho lento, bugs parciais de recursos após login, problemas de corretude de dados e “funciona nos EUA mas não na Europa”. Também não pegam falhas silenciosas como um job em background acumulando backlog antes de afetar cadastros.

Um exemplo concreto: um deploy quebra acidentalmente uma variável de ambiente. Sua homepage pode continuar carregando, mas as requisições de cadastro passam a falhar e webhooks de pagamento param de ser processados. Com apenas esses alertas, você encontra o problema em minutos em vez de esperar por uma reclamação.

Alerta 1: Site inacessível (cheque simples de uptime)

Se for configurar apenas um alerta, que seja um check de disponibilidade que responda a uma pergunta: uma pessoa real consegue carregar seu produto agora?

Uma configuração prática usa três alvos. Cheque sua homepage para pegar falhas de DNS, CDN e hospedagem básica. Cheque uma página app shell (uma rota da app deslogada que carrega JavaScript e CSS) para capturar builds quebrados e problemas de assets. Depois cheque um endpoint de health de API leve que retorne um 200 rápido com payload mínimo, o que pega crashes do backend mesmo quando a homepage ainda carrega.

Checks de uptime podem enganar se você depender de um único local. Use pelo menos duas regiões (ou dois checks independentes) e só trate o site como “down” quando ambos falharem na mesma janela curta. Isso evita pager por causa de um data center ou ISP com problema.

Quando um alerta dispara, deve ser imediatamente acionável. Inclua a URL exata que falhou, horário da primeira falha e da falha mais recente, onde falhou (região/local), que tipo de falha foi (status code, timeout, DNS, TLS), e o último horário de sucesso conhecido.

Para paging vs notificações em chat, mantenha uma regra simples. Page quando o app shell ou o health da API falharem duas vezes seguidas (por exemplo, em 2–3 minutos). Envie só para chat em caso de uma única checagem falhada, ou para uma falha da homepage quando o app shell ainda funciona.

Alerta 2: Cadastros falhando (seu crescimento para silenciosamente)

Se o site está no ar mas as pessoas não conseguem criar contas, você pode perder um dia inteiro de crescimento sem notar. Monitorar cadastros é um dos alertas de maior valor que você pode adicionar.

Escolha um caminho crítico e teste de ponta a ponta: abra a página de cadastro, submeta o formulário, verifique que o usuário foi criado e confirme que a app consegue logar (ou que se chega ao passo “verifique seu e-mail” se usar verificação por e-mail). A ideia é pegar quebras reais, não apenas “a página retornou 200 OK”.

O que monitorar (fique focado no resultado)

Mire em poucos sinais que correspondam a como o fluxo realmente funciona. Observe a taxa de sucesso da jornada completa de cadastro, mais taxas de erro e latência dos endpoints de cadastro e login. Adicione um backstop de negócio: alerte se a contagem de novos usuários cair para zero (ou perto disso) em uma janela que faça sentido para seu tráfego.

Esse backstop importa porque algumas falhas escapam de checagens sintéticas. Um endpoint pode continuar retornando “success”, mas a entrega de e-mail falha, ou um país fica bloqueado, e cadastros reais param silenciosamente.

Configure o alerta para disparar em falhas sustentadas, não num único pico. Para muitos produtos, “3 checagens de cadastro falhadas em 5 minutos” é um gatilho mais forte do que uma falha isolada.

Alerta 3: Pagamentos ou webhooks falhando (dinheiro e fulfillment)

Pagamentos são onde pequenos bugs viram dano real rápido. Esse alerta é menos sobre “o site está no ar?” e mais sobre “recebemos o dinheiro e entregamos o que prometemos?”.

Dois pontos de quebra aparecem com mais frequência. O primeiro é a criação do checkout/pagamento falhar (config ruim, redirects quebrados, problemas com provedor). O segundo é o processamento de webhooks falhar: o pagamento acontece, mas sua app nunca processa o evento que concede acesso, credita conta, inicia fulfillment ou envia confirmação.

Um sinal forte é direto: monitore a taxa de sucesso no processamento de webhooks e a idade do backlog. Se eventos estão se acumulando, algo está travado mesmo que clientes ainda possam pagar. Se a taxa de sucesso cair, o handler está falhando, a verificação de assinatura quebrou, ou um deploy mudou o parsing do payload.

Mantenha o monitoramento atrelado a resultados. Eventos de sucesso de pagamento e criação de entitlements devem ficar próximos. Observe tentativas repetidas de webhook, aumento de respostas 4xx/5xx e a idade do evento não processado mais antigo. Se tiver um canal de suporte, relatórios de “paguei mas não tenho acesso” também são um sinal secundário útil.

Se seu provedor suportar, adicione um canário agendado em ambiente seguro para confirmar o caminho completo: criar pagamento, receber webhook, conceder direito, enviar confirmação.

Como configurar esses alertas passo a passo

Pense como um usuário de primeira vez. O objetivo não é monitorar tudo. É capturar quebras iniciais com três checagens pequenas e repetíveis.

1) Defina as ações exatas que vai simular

Escreva as menores ações que provam que o produto ainda funciona: carregar a página inicial, criar uma conta e completar o loop de pagamento ou webhook. Seja específico (por exemplo, “submeter formulário de cadastro com um e-mail novo”), porque checagens vagas são difíceis de automatizar e fáceis de interpretar mal durante um incidente.

2) Mantenha cada alerta mínimo: 1–2 endpoints

Para cada alerta, escolha um endpoint primário e um sinal backup se necessário. “Site down” pode ser o app shell mais um endpoint de health leve. “Cadastros falhando” pode ser o POST de cadastro mais uma verificação rápida de que o registro do usuário existe. “Pagamentos/webhooks falhando” pode ser o endpoint que recebe webhooks mais uma checagem de que o fulfillment iniciou.

3) Defina agenda e tentativas para reduzir falsos positivos

Execute checagens com frequência suficiente para notar problemas rapidamente (cada 1–5 minutos é comum), mas faça retries antes de pager. Um padrão simples é 2–3 tentativas em 1–2 minutos, e só alertar se todas falharem. Configure timeouts para que serviços lentos gerem avisos antes de se tornarem uma queda completa.

4) Decida quem recebe notificações e como

Escolha um dono por alerta para que não vire “alguém resolve”. Notifique a pessoa on-call primeiro e envie cópia para um canal compartilhado para que outros possam ajudar se o incidente durar.

5) Adicione um runbook de uma linha a cada alerta

Coloque a primeira ação dentro da própria mensagem do alerta:

• Site down: checar status da hospedagem e o último deploy, depois reverter se necessário.
• Cadastros falhando: tentar um cadastro manual, checar logs do provedor de auth e gravações no banco.
• Pagamentos/webhooks falhando: confirmar status do provedor, depois inspecionar logs de webhook e fila/backlog.

Thresholds, tempos e quem é pagado

Bons alertas de interrupção são rápidos, mas não nervosos. Você quer pegar falhas reais cedo sem acordar alguém por um pico de um minuto.

Thresholds simples para começar (padrões seguros)

Comece por aqui e ajuste depois de uma semana com dados reais:

• Site inacessível (uptime): cheque a cada 1 minuto, page após 2 checagens falhas seguidas, idealmente de 2 locais.
• Cadastros falhando: execute um cadastro sintético a cada 5 minutos, avise após 2 falhas consecutivas, page após 3 falhas (cerca de 15 minutos).
• Pagamentos/webhooks falhando: avise se a taxa de falha > 2% por 10 minutos (ou 10 falhas em 5 minutos); page se a taxa de falha > 5% por 10 minutos ou qualquer sequência sustentada de falhas graves.

Esses números não são mágicos. São um ponto de partida sólido para que seus alertas sejam úteis desde o dia um.

Use a regra de “dois acertos” para cortar ruído

A maioria das equipes recebe excesso de alertas porque alerta no primeiro erro. Uma correção simples é exigir confirmação.

Exemplo: se seu check de uptime falhar uma vez, envie um aviso. Se falhar duas vezes seguidas, page a pessoa on-call.

Direcione alertas para o dono certo

Quem recebe page deve ser quem pode consertar mais rápido:

• Site down: on-call de engenharia (backend ou infra).
• Cadastros falhando: on-call de backend, mais produto como aviso.
• Pagamentos/webhooks falhando: on-call de backend, mais o responsável por pagamentos como aviso.

Se esses alertas dispararem constantemente, não os silencie. Trate como sinal de que um caminho crítico é frágil e precisa de trabalho.

Faça os alertas acionáveis (o que a mensagem precisa conter)

Um alerta só é útil se alguém puder dar o primeiro passo em menos de um minuto. Muitos alertas ruins dizem o que quebrou, mas não o que fazer em seguida ou quem é o dono.

Mantenha o payload consistente entre as três checagens para que cada alerta leia como um mini ticket de incidente. No mínimo, inclua: o que falhou (e impacto para o usuário em palavras simples), onde falhou (ambiente/região e URL exata), quando começou e há quanto tempo está acontecendo, evidências (status code, trecho de erro, request ou trace ID), e o dono (serviço/time e rotação on-call).

Adicione um pouco de contexto que frequentemente explica incidentes rápido: versão e horário do deploy atual, estado de feature flags relevantes e mudanças de configuração recentes como rotação de segredos, atualização de URL de webhook ou mudança de chave do provedor de pagamento.

Para instruções, mantenha curto: um passo de verificação, um conserto provável primeiro (reverter ou desabilitar uma flag nova) e um caminho claro de escalonamento.

Checagens rápidas: checklist de 60 segundos para uma interrupção

Quando algo parece errado, você não precisa de investigação completa para confirmar. Precisa de uma sequência rápida que responda: o site é alcançável, um novo usuário pode entrar, e eventos de dinheiro/fulfillment ainda funcionam?

Execute estas em ordem:

• Confirme uptime de duas localidades (uma local, outra remota). Se uma falhar e a outra passar, suspeite de DNS ou problema regional.
• Crie um usuário de teste novo e complete o fluxo de cadastro, incluindo verificação de e-mail se usar.
• Dispare um evento de webhook de teste (ou uma compra de teste) e confirme que o processamento está acompanhando. Procure por backlog crescendo.
• Faça um pagamento real pequeno de ponta a ponta e confirme que o acesso é concedido ou o pedido marcado como cumprido. Se o pagamento for aprovado mas o acesso não for concedido, os usuários vão notar rápido.
• Escaneie sinais-chave de erro: picos em 401/403, 500s ou timeouts geralmente apontam para um deploy ruim, segredo expirado ou auth mal configurada.

Se qualquer passo falhar, pause deploys e reverta a mudança mais recente se possível. Capture o que viu (timestamp, endpoint, texto do erro, ID do usuário ou pedido) para que quem conserta não tenha que adivinhar.

Exemplo: um deploy ruim e como os três alertas ajudam

Uma pequena SaaS entrega uma mudança “rápida” numa sexta-feira à noite: um middleware novo que valida headers antes das requisições chegarem à app. Passa nos testes locais, é deployado, e a equipe fecha os laptops.

Dez minutos depois, o primeiro sinal aparece. Não uma enxurrada de logs, apenas três checagens voltadas ao usuário.

O check de site falha primeiro: a homepage ainda carrega, mas rotas-chave da app retornam 500s, então o uptime captura isso. O check de cadastro falha na sequência: contas deixam de ser criadas, confirmando que não é apenas “tráfego baixo”. Depois o check de pagamentos/webhooks mostra retries e backlog crescendo, revelando que eventos de pagamento não estão sendo processados.

Em 15 minutos a equipe restringe o problema comparando o que ainda funciona (páginas estáticas) com o que falha (tudo protegido pelo novo middleware). Identificam uma exigência de header que bloqueia callbacks de auth e requisições de provedores de pagamento.

Eles revertem para restaurar cadastros e pagamentos, e depois mandam um hotfix: permitir rotas conhecidas de webhook e callbacks de auth, e logar requisições bloqueadas com motivo claro. Depois, trocam os checks de cadastro e webhook para contas canário dedicadas e eventos de teste para que falhas sejam fáceis de confirmar sem afetar clientes reais.

Erros comuns que tornam esses alertas inúteis

A forma mais rápida de perder confiança nos alertas é torná-los barulhentos, vagos ou cegos para a dor real do usuário. A maioria das equipes não precisa de mais alertas. Precisa de menos alertas que apontem uma falha específica e um próximo passo claro.

Modos de falha comuns:

• Só checar “servidor está no ar”. Um 200 OK na homepage pode esconder login quebrado, cadastro quebrado ou checkout travado.
• Pager por todo erro sem threshold. Um timeout isolado é normal. Page em taxas sustentadas numa janela curta.
• Assumir que entrega de webhook significa sucesso. Providers podem dizer “entregue” mesmo se seu endpoint retorna 500, timeouts, ou perde dados após o parsing. Teste receive, validação, armazenamento e gatilho do próximo passo.
• Ignorar a frequência de mudanças em auth e segredos. Chaves rotacionadas, apps OAuth expiradas e variáveis de ambiente mal configuradas podem quebrar cadastros silenciosamente.
• Sem dono e sem runbook. Se o alerta não diz quem é o dono e como verificar a recuperação, você perde os primeiros 15 minutos.

Mantenha o texto do alerta prático: o que quebrou, onde (endpoint ou fluxo), quantos usuários são afetados se puder estimar, e um passo de verificação.

Próximos passos: mantenha simples e torne confiável

Se não fizer mais nada, mantenha essas três checagens: site inacessível, cadastros falhando e pagamentos ou webhooks falhando. Elas geralmente avisam que algo está errado antes que os usuários encham sua caixa de entrada.

Depois disso, adicione apenas um alerta por vez, e só se você souber responder duas perguntas: que ação você tomará quando ele disparar, e com que frequência ele deve disparar numa semana normal? Se não souber responder ambas, provavelmente é ruído.

Uma maneira simples de manter alertas confiáveis é um teste mensal de 10 minutos. Pegue um momento tranquilo e force cada alerta a disparar uma vez para garantir que ainda funcionam.

Se você herdou uma base de código gerada por IA e esses alertas continuam apontando aos mesmos pontos frágeis (auth, segredos, handlers de webhook), geralmente é mais rápido consertar o fluxo subjacente do que continuar afinando thresholds. FixMyMess (fixmymess.ai) foca em diagnosticar e reparar esses caminhos de produção para que seu monitoramento fique quieto pelo motivo certo: a aplicação realmente aguenta tráfego real.