---
title: "A fadiga de alertas é real: como bons desenvolvedores realmente resolvem isso"
description: "Quando todo alerta parece igualmente urgente, nada parece urgente. Veja como ajustar seu monitoramento com notificações em níveis — e quais ferramentas se dão bem com o Echobell."
date: 2026-04-17
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - fadiga de alertas
  - monitoramento
  - Sentry
  - Prometheus
  - CloudWatch
  - DevOps
---

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

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`:

```yaml
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:

```python
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:

| Canal | Tipo | Quem se inscreve |
|---|---|---|
| `production-api-critical` | Chamada | Pessoa de plantão |
| `production-api-warnings` | Urgente | Time de dev inteiro |
| `staging-all` | Normal | Time de dev (opcional) |
| `background-jobs` | Normal | Quem tiver interesse |

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](/pt/blog/phone-call-alerts-api-downtime)
- [Notificações em chamada do Grafana com o Echobell](/pt/blog/grafana-call-notification)
- [Como driblar o modo Foco do iOS em alertas críticos](/pt/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [Condições de janela de tempo para entregar alertas de forma mais inteligente](/pt/blog/time-window-notifications-using-utc-conditions)
- [Montando um hub de automação com n8n e Echobell](/pt/blog/n8n-echobell-automation-hub)
- [Notificações por webhook para iPhone](/pt/features/webhooks)