O alerta que ninguém atende

Existe um estágio previsível na vida de um monitoramento. Ele começa útil, ganha regra a cada incidente e, alguns meses depois, dispara tanto que a equipe cria uma pasta no e-mail para os avisos não atrapalharem o trabalho.

A partir daí, o monitoramento não protege mais nada. Ele só produz ruído — e o incidente real chega no meio de trezentos avisos que ninguém lê.

O erro de origem quase sempre é o mesmo: tratar alerta como registro. Registro serve para consulta depois; alerta serve para interromper alguém agora. São coisas diferentes e não deveriam usar o mesmo canal.

Um alerta que se sustenta responde a três perguntas antes de existir:

• O que exatamente está errado, em termos que quem recebe entende sem abrir o console?
• Quem precisa saber disso, nominalmente, e por qual canal?
• O que essa pessoa deve fazer ao receber?

Se a resposta da terceira pergunta for "olhar e ver se piora", não é alerta. É informação, e informação vai para o painel e para o relatório.

A criticidade também precisa ser real. Vale dizer em voz alta, na hora de definir, o que cada nível significa em consequência humana: crítico significa acordar alguém às três da manhã. Se o time não está disposto a fazer isso por aquele evento, ele não é crítico — e classificá-lo assim só ensina todo mundo a ignorar o que é.

Algumas correções que costumam devolver a utilidade do painel:

• Alertar por sintoma percebido pelo usuário, não por métrica isolada. "A página de checkout está fora" vale mais que "o uso de CPU passou de 80%".
• Agrupar eventos da mesma causa: um banco fora do ar não deve gerar quarenta avisos, um por serviço que depende dele.
• Dar tempo antes de disparar. Muita coisa se resolve sozinha em trinta segundos, e alertar sobre ela é ensinar a equipe a esperar passar.
• Revisar periodicamente o que disparou e não gerou ação nenhuma. Alerta que nunca virou ação é candidato a virar registro.
• Escrever no próprio alerta o primeiro passo esperado de quem atender.

Vale ainda medir o que o painel não mostra: quantos alertas foram fechados sem nenhuma ação. É o número que revela fadiga antes de a equipe reclamar — e antes de o incidente que importava passar despercebido.

Automatizar a correção é possível, mas com limite claro: só onde o comportamento é conhecido e a ação é segura de repetir. Reiniciar um serviço que trava de forma previsível é razoável; automatizar em cima de um problema que ninguém entendeu ainda apenas esconde o sintoma e adia o diagnóstico.

Monitoramento bom não é o que enxerga mais coisas. É o que interrompe menos gente, e sempre por um bom motivo.