Gerenciar Incidentes
Incidentes são eventos de queda ou degradação que ficam visíveis na sua Status Page pública. Gerenciá-los bem — com comunicação rápida e atualizações frequentes — é tão importante quanto resolver o problema técnico em si.
Como incidentes são criados
Automaticamente (via monitor)
Quando um monitor ultrapassa o failureThreshold, o TheAlert:
- Abre um incidente automaticamente
- Vincula o incidente ao monitor correspondente
- Exibe o incidente como "Em andamento" na Status Page pública
- Registra hora exata de início
O incidente é fechado automaticamente quando o monitor se recupera (ultrapassa o recoveryThreshold).
Manualmente
Você também pode criar incidentes manualmente para comunicar manutenções planejadas ou problemas que não foram detectados automaticamente:
Status Pages → sua Status Page → "Novo Incidente"
Adicionando atualizações ao incidente
Durante um incidente, comunicar o progresso é fundamental. Para adicionar uma atualização:
- Acesse o incidente (via Dashboard ou Status Pages)
- Clique em "Adicionar Atualização"
- Selecione o status da atualização:
| Status | Quando usar |
|---|---|
| Investigando | Você identificou o problema mas ainda não sabe a causa |
| Identificado | Causa raiz encontrada, trabalho em andamento |
| Monitorando | Fix aplicado, verificando estabilidade |
| Resolvido | Incidente encerrado |
- Escreva a mensagem de atualização
- Clique em "Publicar Atualização"
A atualização aparece imediatamente na Status Page pública com timestamp.
Exemplo de timeline de incidente
15:32 BRT — Investigando
Identificamos falhas na API de Pagamentos. Nossa equipe está investigando.
15:45 BRT — Identificado
Identificamos a causa: sobrecarga no banco de dados após deploy de nova feature.
Realizando rollback.
16:02 BRT — Monitorando
Rollback concluído. API voltou a responder normalmente.
Monitorando por 15 minutos para confirmar estabilidade.
16:17 BRT — Resolvido
API de Pagamentos operando normalmente. Duração total: 45 minutos.
Post-mortem será publicado em 24 horas.Resolvendo um incidente manualmente
Se o monitor se recuperou mas você quer fechar o incidente com uma mensagem final:
- Acesse o incidente
- Adicione uma atualização com status "Resolvido"
- O incidente é fechado e a Status Page atualiza automaticamente
Mesmo que você não feche manualmente, o incidente é fechado automaticamente quando o monitor volta ao estado UP (após atingir o recoveryThreshold).
O que os usuários veem
Durante o incidente
A Status Page exibe imediatamente:
⚠ INCIDENTE EM ANDAMENTO
━━━━━━━━━━━━━━━━━━━━━━━━
API de Pagamentos — Partial Outage
Iniciado: 15:32 BRT (há 23 minutos)
Última atualização (15:45):
Identificamos a causa: sobrecarga no banco de dados.
Realizando rollback.O componente afetado fica destacado com status amarelo (DEGRADED) ou vermelho (DOWN).
Após a resolução
O incidente fica no histórico com toda a timeline:
API de Pagamentos — Resolvido
15 de março de 2026
Duração: 45 minutos
[Ver timeline completa]Histórico de incidentes
Todos os incidentes ficam registrados na Status Page pública, dando visibilidade ao histórico de disponibilidade. Isso demonstra transparência e permite que clientes vejam tendências ao longo do tempo.
Boas práticas de comunicação de incidentes
Comunique rapidamente, mesmo sem saber a causa A pior coisa durante um incidente é silêncio. Poste uma atualização "Investigando" logo nos primeiros 5 minutos, mesmo que você ainda não saiba o que está acontecendo. Isso mostra que você está ciente e trabalhando.
Use linguagem clara e não técnica Sua Status Page é lida por clientes, não por engenheiros. Em vez de "Timeout na conexão TCP com o primary node do PostgreSQL", escreva "Estamos com lentidão no processamento de pedidos".
Atualize a cada 15-30 minutos durante incidentes Mesmo que não haja novidade, uma atualização "Ainda investigando, sem novidades no momento" é melhor do que silêncio prolongado.
Sempre publique uma mensagem de resolução Quando o incidente acabar, publique uma mensagem final explicando o que foi resolvido. Considere incluir um breve resumo da causa raiz.
Publique post-mortems para incidentes maiores Para incidentes com mais de 30 minutos de duração ou impacto significativo, publique um post-mortem em até 48 horas. Inclua: linha do tempo, causa raiz, ações corretivas. Isso constrói confiança com clientes técnicos.
Não delete incidentes do histórico Alguns times deletam incidentes para "limpar" o histórico. Isso é contraproducente e pode ser percebido como desonestidade. Manter o histórico completo demonstra maturidade operacional.