Thresholds de Alerta

Os thresholds controlam quando o TheAlert dispara alertas. Configurá-los corretamente é o equilíbrio entre detectar problemas rapidamente e evitar ruído com falsos positivos.

Thresholds customizáveis estão disponíveis no plano STARTER ou superior. O plano FREE usa os valores padrão (failureThreshold: 2, recoveryThreshold: 2).

failureThreshold

Define quantas falhas consecutivas são necessárias antes de abrir um incidente e disparar alertas.

Padrão: 2

Como funciona

Intervalo: 60 segundos | failureThreshold: 2

14:00:00  Check → DOWN  (falha 1/2) — nenhum alerta
14:01:00  Check → DOWN  (falha 2/2) — INCIDENTE ABERTO, ALERTA DISPARADO
14:02:00  Check → DOWN  — incidente já aberto, sem novo alerta
14:03:00  Check → UP    — inicia contagem de recovery

Por que não usar failureThreshold: 1?

Falhas únicas são comuns em redes distribuídas:

Timeout de DNS transiente
Reinicialização rápida do processo (< 5 segundos)
Blip de rede temporário
Timeout de TCP por sobrecarga pontual

Com failureThreshold: 1, esses eventos disparariam alertas a cada ocorrência. Com failureThreshold: 2, você só é alertado quando há pelo menos dois checks consecutivos falhando — indicando um problema real.

Quando usar failureThreshold: 1

Use failureThreshold: 1 quando:

O serviço é absolutamente crítico e qualquer segundo de downtime importa
Você tem um intervalo curto (10-30s) e quer detecção ultra-rápida
O custo de um falso positivo é aceitável em troca da velocidade

Intervalo: 10 segundos | failureThreshold: 1
→ Alerta em ~10 segundos após primeira falha

Impacto no tempo de detecção

Intervalo	failureThreshold	Tempo mínimo até alerta
5 minutos	2	~10 minutos
60 segundos	2	~2 minutos
60 segundos	1	~1 minuto
30 segundos	2	~1 minuto
10 segundos	2	~20 segundos
10 segundos	1	~10 segundos

recoveryThreshold

Define quantas recuperações consecutivas são necessárias antes de fechar o incidente e enviar o alerta de recuperação.

Padrão: 2

Como funciona

recoveryThreshold: 2

14:05:00  Check → UP  (recovery 1/2) — nenhum alerta de recuperação
14:06:00  Check → UP  (recovery 2/2) — INCIDENTE FECHADO, ALERTA DE RECOVERY

Por que não usar recoveryThreshold: 1?

Evita alertas de recuperação prematuros quando o serviço oscila:

DOWN → UP → DOWN → UP → DOWN ...  (flapping)

Com recoveryThreshold: 1 → múltiplos alertas de recovery
Com recoveryThreshold: 2 → alertas suprimidos até estabilização

Quando usar recoveryThreshold: 1

Use quando você quer ser notificado assim que o serviço responder novamente, sem aguardar confirmação. Útil em incidentes onde a equipe já está com a atenção focada.

Flapping protection

O TheAlert detecta automaticamente o flapping — quando um monitor fica alternando rapidamente entre UP e DOWN.

O que é flapping

14:00  DOWN
14:01  UP
14:02  DOWN
14:03  UP
14:04  DOWN  ← detectado como flapping

O que acontece durante flapping

O estado é marcado como FLAPPING
Alertas são suprimidos por um período de cooldown
Checks continuam rodando normalmente
O histórico registra todos os estados reais
Quando o serviço se estabilizar (UP ou DOWN consistentemente), as notificações retomam

Por que flapping acontece

Serviço sobrecarregado respondendo intermitentemente
Deploy em andamento com containers reiniciando
Memory leak causando crashes periódicos
Load balancer removendo e adicionando instâncias
Problema de rede intermitente

⚠️

Flapping frequente é um sinal de problema real. Não aumente os thresholds para eliminar o flapping — investigue a causa raiz.

Configurando thresholds por monitor

Para ajustar os thresholds de um monitor específico:

Acesse o monitor → clique em "Editar"
Expanda "Configurações de Alerta"
Ajuste failureThreshold e recoveryThreshold
Salve

Ou via API:

curl -X PUT https://api.thealert.io/api/v1/monitors/mon_abc123 \
  -H "Authorization: Bearer ta_sua_chave" \
  -H "Content-Type: application/json" \
  -d '{
    "failureThreshold": 1,
    "recoveryThreshold": 1
  }'

Recomendações por tipo de serviço

Serviços críticos de pagamento / autenticação

failureThreshold: 1
recoveryThreshold: 2
intervalo: 10-30 segundos (PRO/BUSINESS)

Detecção máxima. Qualquer falha deve ser conhecida imediatamente.

APIs de produto principal

failureThreshold: 2
recoveryThreshold: 2
intervalo: 30-60 segundos

Equilíbrio padrão. Boa detecção sem excesso de alertas.

Sites e landing pages

failureThreshold: 2
recoveryThreshold: 2
intervalo: 1-5 minutos

Menos crítico. Downtime de 5-10 minutos é aceitável para investigar.

Cron jobs (Heartbeat)

failureThreshold: 1
recoveryThreshold: 1
intervalo: conforme frequência do cron

Heartbeat é binário: ou pingou ou não pingou. Thresholds 1/1 são mais adequados.

Monitoramento DNS / SSL

failureThreshold: 2
recoveryThreshold: 2
intervalo: 5 minutos

DNS e SSL não mudam com frequência. Um intervalo maior com threshold padrão é suficiente.

Próximos passos

Janelas de Manutenção Equipe