A fadiga de alertas é real: como bons desenvolvedores realmente resolvem isso

Sumário

• Por que a maioria dos monitoramentos gera mais ruído do que sinal
• A abordagem em três níveis
• Sentry: pare de ser acionado por cada exceção do Python
• Prometheus e AlertManager: roteie por severidade
• AWS CloudWatch: SNS → Lambda → Echobell
• Transformando o roteamento de alertas em uma decisão do time
• O teste da relação sinal-ruído
• Uma mudança de cada vez
• Relacionados

Existe um nome para isso: fadiga de alertas. É o que acontece quando suas ferramentas de monitoramento mandam tantas notificações que seu cérebro passa a filtrá-las automaticamente — inclusive as que importam.

Costuma começar pequeno. Você configura alertas por e-mail para cada erro 5xx. Depois notificações no Slack para cada build que falha. Depois pings do Datadog, e-mails do Sentry, SMS do UptimeRobot. Em um mês, seu celular vibra 50 vezes por dia e nada disso parece urgente. A pior parte? Quando algo realmente quebra, você já se treinou para ignorar.

A fadiga de alertas destrói o tempo de resposta. E um tempo de resposta ruim destrói produtos.

Por que a maioria dos monitoramentos gera mais ruído do que sinal

O problema de fundo é que a maioria das ferramentas de alerta trata todos os eventos da mesma forma. Um teste instável que falha em 10% das vezes recebe o mesmo formato de notificação que "a API de pagamentos está retornando 500 para todo usuário". Um deles precisa de uma ligação às 2 da manhã. O outro provavelmente deveria aparecer em um resumo semanal.

Quando tudo recebe o mesmo tratamento, as pessoas começam a ignorar tudo.

A solução não é ter menos alertas — é entregá-los de forma mais inteligente. O mesmo evento com níveis de severidade diferentes, ou com frequências diferentes, deveria produzir níveis de urgência diferentes no seu celular.

A abordagem em três níveis

O Echobell oferece três modos de entrega, e usar bem os três é o jogo todo:

• Normal (Active): notificação push padrão. Serve para eventos informativos que não exigem ação imediata.
• Urgente: atravessa o modo Foco do iOS. Bom para coisas que precisam de atenção na próxima hora ou duas.
• Chamada: faz o celular tocar como uma ligação recebida. Reserve isso para "resolva agora ou haverá consequências reais".

O objetivo é preservar o nível de chamada para eventos em que uma resposta atrasada tem consequências de verdade — receita perdida, falhas em cascata, dados de usuários em risco. Todo o resto cai para urgente ou menos.

Sentry: pare de ser acionado por cada exceção do Python

O Sentry é o exemplo clássico de fadiga de alertas. Por padrão, ele envia um e-mail para cada novo tipo de issue. Em uma base de código ativa, durante uma semana comum, isso é uma mangueira de incêndio.

Uma configuração mais inteligente:

1. No Sentry, vá em Alerts → Create Alert → Issue Alert
2. Adicione uma condição: The issue is seen more than 10 times in 1 hour
3. Adicione a ação: Send a notification via webhook → cole a URL do seu canal do Echobell
4. Defina o tipo de notificação do canal como time-sensitive

Para caminhos realmente críticos — exceções não tratadas em fluxos de pagamento, falhas de autenticação, corrupção de dados — crie um alerta separado com um limite mais baixo e um canal do Echobell no nível calling. Esse canal só toca quando algo naquele caminho específico quebra.

O resultado: as issues rotineiras se acumulam em silêncio no seu painel do Sentry. Os problemas que derrubam a produção fazem seu celular tocar.

Prometheus e AlertManager: roteie por severidade

Se você roda Prometheus, já tem o AlertManager cuidando do roteamento. Dá para enviar alertas direto ao Echobell adicionando-o como um receptor de webhook.

No seu alertmanager.yml:

receivers:
  - name: echobell-critical
    webhook_configs:
      - url: https://hook.echobell.one/t/<channel-token>
        send_resolved: true

  - name: slack-warnings
    slack_configs:
      - api_url: YOUR_SLACK_WEBHOOK

route:
  group_by: ['alertname', 'job']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: slack-warnings
  routes:
    - match:
        severity: critical
      receiver: echobell-critical

Com essa configuração, os alertas com severity: critical vão para o Echobell e fazem seu celular tocar; os avisos vão para o Slack, onde podem esperar até de manhã. Você não precisa mudar uma única regra do Prometheus — basta adicionar a camada de roteamento no AlertManager.

Defina o próprio canal do Echobell como Chamada. Se o AlertManager marcou como crítico, merece um toque de verdade.

AWS CloudWatch: SNS → Lambda → Echobell

O CloudWatch não tem saída nativa por webhook, mas você chega lá em poucos minutos com o SNS e uma pequena função Lambda.

1. Crie um tópico SNS e associe-o ao seu alarme do CloudWatch
2. Crie uma função Lambda inscrita nesse tópico:

import json
import urllib.request

def lambda_handler(event, context):
    message = json.loads(event['Records'][0]['Sns']['Message'])
    alarm_state = message.get('NewStateValue', 'UNKNOWN')

    payload = {
        "title": f"AWS: {message['AlarmName']}",
        "body": message.get('NewStateReason', 'No details'),
        "notificationType": "calling" if alarm_state == "ALARM" else "active"
    }

    req = urllib.request.Request(
        'https://hook.echobell.one/t/<channel-token>',
        data=json.dumps(payload).encode(),
        headers={'Content-Type': 'application/json'},
        method='POST'
    )
    urllib.request.urlopen(req)

Esse padrão funciona para qualquer serviço da AWS que suporte SNS: eventos do RDS, falhas de serviços do ECS, alertas de limite de faturamento, mudanças de estado de instâncias EC2. Adicione uma Lambda, conecte-a ao SNS e todo alarme do CloudWatch vira uma ligação quando realmente dispara.

Transformando o roteamento de alertas em uma decisão do time

O verdadeiro ganho com alertas em níveis é tornar a decisão de roteamento explícita — e não algo que uma pessoa configurou uma vez e ninguém mais consegue encontrar.

Uma estrutura prática para um time pequeno de engenharia:

Quando a escala de plantão muda, quem está saindo cancela a inscrição no canal crítico e quem está entrando se inscreve. Essa é toda a passagem de plantão — sem arquivos de configuração, sem painéis de administração.

Os canais do Echobell podem ser compartilhados por link, então a inscrição leva cerca de 10 segundos para cada novo integrante do time.

O teste da relação sinal-ruído

Antes de adicionar qualquer alerta novo, faça uma pergunta: se isso disparar às 3 da manhã de uma sexta-feira, o que eu de fato faço?

• "Acordar e resolver na hora" → Chamada
• "Cuidar disso logo de manhã" → Urgente ou Normal
• "Provavelmente nada, eu voltaria a dormir" → repense se o alerta deveria existir

A maioria dos monitoramentos tem coisas demais na primeira categoria e de menos na segunda. A resposta certa para a maior parte dos eventos é "resolvo amanhã", e uma notificação urgente que aparece na tela de bloqueio sem tocar é exatamente a ferramenta certa para isso.

Uma mudança de cada vez

Se sua configuração atual está produzindo fadiga de alertas, a solução mais rápida não é uma reforma completa. Escolha a sua fonte mais barulhenta — provavelmente os e-mails do Sentry ou um canal do Slack que todo mundo silenciou — e classifique cada tipo de evento em chamada, urgente ou normal.

Uma fonte. Uma semana. Veja se o ruído cai sem perder sinal.

Depois passe para a próxima.

Uma configuração de alertas bem ajustada é uma daquelas coisas que melhoram o seu dia a dia de trabalho em silêncio, sem drama. Você para de temer o celular. E passa a confiar que, quando ele toca, é porque importa.

---

Relacionados

• Receber alertas por ligação quando sua API cai
• Notificações em chamada do Grafana com o Echobell
• Como driblar o modo Foco do iOS em alertas críticos
• Condições de janela de tempo para entregar alertas de forma mais inteligente
• Montando um hub de automação com n8n e Echobell
• Notificações por webhook para iPhone