Visão Geral de Alertas
O sistema de alertas do TheAlert notifica sua equipe quando um monitor muda de estado. Esta página explica como os alertas funcionam, quais canais estão disponíveis e como configurar thresholds para evitar falsos positivos.
Quando um alerta é disparado
Alertas são disparados em mudanças de estado de um monitor:
| Transição | Tipo de alerta |
|---|---|
| UP → DOWN | Alerta de queda (DOWN alert) |
| UP → DEGRADED | Alerta de degradação |
| DOWN → UP | Alerta de recuperação |
| DEGRADED → UP | Alerta de recuperação |
Você recebe no máximo dois alertas por incidente: um na queda e um na recuperação. Não há spam enquanto o serviço permanece no mesmo estado.
failureThreshold — evitando falsos positivos
O failureThreshold define quantas falhas consecutivas são necessárias antes de disparar o alerta de DOWN. Padrão: 2.
Check 1: DOWN ← falha 1/2 — nenhum alerta
Check 2: DOWN ← falha 2/2 — ALERTA DISPARADO
Check 3: DOWN ← incidente já aberto, nenhum alerta adicionalPor que o padrão é 2?
Falhas únicas e transitórias são comuns em redes distribuídas — um timeout pontual de DNS, um blip de rede, uma reinicialização rápida de processo. Com failureThreshold: 1, esses eventos disparariam alertas desnecessários. Com failureThreshold: 2, você só é alertado quando há uma falha consistente.
Efeito no tempo de detecção
Com failureThreshold: 2 e intervalo de 60s, o alerta é disparado após 2 minutos de downtime (2 checks × 1 minuto). Se você precisa de detecção mais rápida, reduza o intervalo ou o threshold.
| Intervalo | failureThreshold | Tempo até alerta |
|---|---|---|
| 60s | 2 | ~2 minutos |
| 60s | 1 | ~1 minuto |
| 30s | 2 | ~1 minuto |
| 10s | 2 | ~20 segundos |
Para serviços críticos de pagamento ou autenticação, considere usar failureThreshold: 1 combinado com um intervalo curto (plano PRO/BUSINESS) para detecção máxima.
recoveryThreshold — confirmando a recuperação
O recoveryThreshold define quantas recuperações consecutivas são necessárias antes de enviar o alerta de recovery. Padrão: 2.
Check DOWN: ...
Check 1: UP ← recuperação 1/2 — nenhum alerta de recovery
Check 2: UP ← recuperação 2/2 — ALERTA DE RECOVERY ENVIADOPor que o padrão é 2? Evita alertas de recuperação prematuros quando o serviço oscila. Se um serviço vai DOWN → UP → DOWN → UP rapidamente, você não quer receber múltiplos alertas de recovery.
Flapping — proteção contra oscilação
Se um monitor ficar alternando entre DOWN e UP rapidamente (fenômeno chamado de flapping), as notificações são suprimidas temporariamente para evitar spam.
DOWN → UP → DOWN → UP → DOWN → [FLAPPING DETECTADO]
notificações suprimidasDurante o estado de flapping:
- Checks continuam sendo executados normalmente
- Incidentes são registrados no histórico
- Alertas são pausados por um período de cooldown
- Quando o serviço se estabiliza (UP ou DOWN consistentemente), as notificações retomam
Flapping frequente geralmente indica um problema real: serviço sobrecarregado, deploy instável, ou problema de infraestrutura. Investigue a causa raiz em vez de aumentar os thresholds.
Canais disponíveis por plano
| Canal | FREE | STARTER | PRO | BUSINESS |
|---|---|---|---|---|
| Sim | Sim | Sim | Sim | |
| Webhook | — | Sim | Sim | Sim |
| Slack | — | — | Sim | Sim |
| Discord | — | — | Sim | Sim |
| Telegram | — | — | Sim | Sim |
Múltiplas integrações
Você pode configurar múltiplos canais simultaneamente. Por exemplo:
- Email para toda a equipe
- Slack no canal
#incidents - PagerDuty via Webhook para escalonamento
Todos os canais configurados recebem o alerta quando o monitor muda de estado.
Selecionando integrações por monitor
Por padrão, uma integração se aplica a todos os monitores do workspace. Para configurar por monitor:
- Acesse o monitor desejado
- Seção "Alertas"
- Selecione quais integrações ativas devem disparar para este monitor específico
Isso permite, por exemplo, alertar o canal #infra apenas para monitores de infraestrutura, e o canal #produto para monitores da aplicação.