O que é fadiga de alertas e como desenhar alertas que a equipe respeita?
O canal de alertas recebe centenas de mensagens por dia. A maioria se resolve sozinha, algumas se repetem há meses e ninguém lembra por quê. Um dia, o alerta que anunciava uma queda de verdade chegou no meio do ruído e foi ignorado. Esse cenário tem nome, fadiga de alertas, e é um dos riscos mais subestimados da operação.
Por que é perigosa
Quando a maior parte dos alertas não exige ação, as pessoas aprendem a não reagir. O tempo de resposta aumenta, alertas são silenciados sem análise e incidentes reais passam despercebidos. Para quem está de plantão, notificações frequentes fora do horário causam desgaste, erros por cansaço e rotatividade.
O problema raramente é falta de monitoramento. É monitoramento sem critério sobre o que merece interromper uma pessoa.
Causas mais comuns
- Limites estáticos genéricos: CPU acima de 80% em todos os servidores, sem considerar o comportamento normal de cada um.
- Alertas por causa em vez de sintoma: dezenas de avisos sobre componentes e nenhum dizendo se o usuário foi afetado.
- Oscilação (flapping): a métrica cruza o limite várias vezes por minuto e gera uma sequência de alertas e normalizações.
- Cascata: uma única falha, como a queda de um link, dispara alertas em todos os itens que dependem dele.
- Alertas órfãos: criados para um problema antigo, sem dono e sem instrução de resposta.
- Manutenções não sinalizadas: mudanças planejadas que geram alertas esperados.
Princípios de um bom alerta
- Acionável: se ninguém precisa fazer nada, não deve ser alerta, e sim registro ou item de painel.
- Por sintoma: priorize o que afeta o usuário ou a meta do serviço, como taxa de erro e latência, e deixe as métricas de causa para o diagnóstico.
- Com urgência proporcional: o que exige ação imediata aciona o plantão; o que pode esperar vira chamado para o horário comercial.
- Com contexto: o alerta informa o serviço, o impacto, o painel relevante e o link para o runbook, o procedimento de resposta.
- Com dono: cada alerta tem uma equipe responsável por mantê-lo.
Técnicas para reduzir o ruído
Exija que a condição persista por alguns minutos antes de alertar e use histerese, um limite para disparar e outro para normalizar, contra a oscilação. Configure dependências entre alertas, para que a queda de um link gere um aviso e não cinquenta; ferramentas como o Zabbix oferecem dependência entre triggers para isso. Agrupe e desduplique notificações do mesmo incidente, cadastre janelas de manutenção e, quando fizer sentido, troque limites fixos pela comparação com o comportamento habitual.
Com SLOs definidos, alertas pela taxa de consumo do error budget costumam substituir dezenas de alertas de limite por poucos e confiáveis.
Medir e revisar
Trate os alertas como um produto que precisa de manutenção. Acompanhe quantos alertas cada plantonista recebe por turno, quantos chegaram fora do horário, a proporção que gerou alguma ação e quais mais se repetem. Em uma revisão periódica, por exemplo quinzenal, cada alerta que disparou sem exigir ação é ajustado, rebaixado para chamado ou removido.
O objetivo é que, quando o telefone tocar de madrugada, ninguém precise se perguntar se vale a pena levantar.
Fadiga de alertas é a perda de reação causada por excesso de notificações sem ação. Alertas por sintoma, acionáveis, com urgência proporcional, contexto e dono, somados a dependências, histerese, janelas de manutenção e revisão periódica, devolvem confiança ao monitoramento.
Este conteúdo foi útil?
Revisão técnica VIPER IT — última atualização em 10 de outubro de 2026.