Todo time de operação conhece essa evolução trágica: primeiro os alertas ajudam, depois incomodam, e por fim viram um canal do Slack que todo mundo silenciou. Quando o incidente sério chega, o aviso estava lá, ignorado no meio de trezentos avisos que não significavam nada.

O fenômeno tem nome (alert fatigue) e uma causa raiz: alertas configurados pelo que é fácil medir, não pelo que exige ação. A filosofia que corrige isso foi bem destilada na literatura de SRE do Google (sre.google), e cabe numa frase:

Todo alerta que acorda alguém precisa ser urgente, acionável e novo. Se falhar em qualquer um dos três, não deveria acordar ninguém.

Alerte sintoma, não causa

O erro estrutural mais comum: alertar sobre CPU alta, memória, disco, fila crescendo. São causas possíveis, e causas possíveis mentem: CPU a 90% pode ser um batch saudável; CPU a 30% pode conviver com o site fora do ar.

O que o usuário sente é o que importa: latência, taxa de erro, disponibilidade do fluxo crítico. Alerte por aí (os sinais que a métrica entrega). O checkout está falhando? Isso é página às 2h da manhã, independentemente da CPU. O disco está em 70%? Isso é um ticket para amanhã, não um toque no celular.

Dois destinos, e nada no meio

Simplicidade que muda tudo: cada alerta tem um de dois destinos.

• Página (acorda gente): o usuário está sofrendo agora, ou vai sofrer em minutos, e uma ação humana muda o desfecho.
• Ticket (fila de trabalho): merece atenção nas próximas horas ou dias, no horário comercial.

O que não se encaixa em nenhum dos dois é dashboard, não alerta. O canal "FYI" de notificações que ninguém lê deve morrer sem culpa: informação sem ação esperada é ruído com uniforme.

As regras do alerta bem construído

1. Acionável ou nada: se a resposta honesta a "o que eu faço quando esse alerta dispara?" é "olho e geralmente ignoro", apague-o hoje.
2. Com runbook: todo alerta aponta para um roteiro: o que verificar, onde olhar, o que fazer. Quem atende às 2h não deveria improvisar do zero.
3. Com duração, não com pico: "erro acima de 2% por 5 minutos" em vez de "qualquer erro". Sistemas espirram; alerta não é para espirro.
4. Baseado em percentual, não em número mágico: "5 erros" significa coisas diferentes com 10 ou 10 mil usuários online. Taxas e percentis envelhecem melhor que valores absolutos.
5. Revisado como código: alerta nasce, envelhece e apodrece. A cada incidente, duas perguntas de retrospectiva: algum alerta inútil disparou? Faltou algum que teria ajudado?

O padrão avançado: alertar pelo orçamento de erro

Times com SLOs definidos dão o passo seguinte: alertar pela velocidade com que o orçamento de erro queima. Em vez de "erro > 2%", a pergunta vira "nesse ritmo, estouramos o SLO do mês em quantas horas?". Queima rápida acorda gente; queima lenta vira ticket. É o alerta com contexto de negócio embutido, e elimina a maior parte dos falsos urgentes.

O teste dos 90 dias

Auditoria simples que fazemos em todo cliente novo: pegue os últimos 90 dias de alertas e classifique cada disparo: levou a uma ação? era urgente de verdade? É comum descobrir que menos de 20% passam no teste. Os outros 80% são o motivo de ninguém mais olhar o canal, e a razão de o alerta importante passar despercebido.

Menos alertas, mais confiáveis, cada um com dono e runbook: essa é a meta. O silêncio do celular volta a significar "está tudo bem", e o toque volta a significar "levanta".

Do canal silenciado ao pager confiável

Redesenhar o alerting (sintomas, severidades, runbooks e a rotina de revisão) é parte do nosso serviço de Observabilidade e Monitoramento, e costuma ser a melhoria de qualidade de vida mais rápida que um time de operação pode comprar.

Quantos dos seus alertas dos últimos 30 dias geraram ação? Faça a conta e conte para a IA da Rabelo Digital, aqui no canto da tela. Ela devolve o diagnóstico. Sem formulário, sem espera.

---

Leia também

• Dashboard de negócio vs dashboard técnico
• MTTR e MTBF: como medir a saúde do seu sistema
• Logs vs Métricas vs Traces: entenda a diferença