Sua API cai às 2 da manhã. A primeira pessoa a perceber é um cliente que tuíta sobre isso. Quando você acorda, há 30 tickets de suporte e um thread no Hacker News sobre sua queda.
Isso é o que acontece quando você não tem alertas onde sua equipe realmente olha. E para a maioria das equipes de engenharia, esse lugar é o Slack.
Neste tutorial, você vai aprender a configurar alertas do Slack para monitoramento de APIs com incoming webhooks (de uma ferramenta de monitoramento ou dos seus próprios scripts), para receber notificações sobre quedas, picos de latência, taxas de erro e expiração SSL no canal onde você já trabalha.
Por que o Slack é o melhor canal para alertas de API?
Engenheiros não checam email às 2 da manhã. Não ficam com um dashboard de monitoramento aberto 24/7. Mas têm o Slack no celular com notificações ativadas para canais específicos.
Slack é onde sua equipe já se comunica sobre incidentes. Quando um alerta de API chega no #ops-alerts, o engenheiro de plantão vê imediatamente, e o resto da equipe tem contexto completo sem perguntar "o que aconteceu?"
Por isso seus alertas deveriam usar Block Kit (o formato de mensagens ricas do Slack), para que você receba notificações estruturadas e acionáveis em vez de texto simples.
Passo 1: Criar um Webhook do Slack
Primeiro você precisa de uma URL de webhook do Slack:
- Acesse api.slack.com/apps e clique em Create New App
- Selecione From scratch, nomeie como "API Alerts" e escolha seu workspace
- Na barra lateral, clique em Incoming Webhooks e ative
- Clique em Add New Webhook to Workspace
- Selecione o canal para alertas (ex:
#ops-alerts) - Copie a URL do webhook gerada
https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXXPasso 2: Enviar alertas para o webhook
Se você usa uma ferramenta de monitoramento, procure a integração de Slack ou de webhooks: cole a URL, envie uma notificação de teste para confirmar que chega no canal certo e salve.
Se você roda seus próprios checks, enviar um alerta é uma única requisição HTTP. Inclua um campo text como fallback e os blocks para a mensagem formatada:
curl -X POST -H 'Content-Type: application/json' \
--data '{
"text": "API Down: POST /v1/checkout returned 503",
"blocks": [
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "*API Down*: Payment API\n*Endpoint:* POST /v1/checkout\n*Status:* 503 Service Unavailable"
}
}
]
}' \
"$SLACK_WEBHOOK_URL"Guarde a URL do webhook como segredo (variável de ambiente, nunca commitada no repositório).
Passo 3: Configurar Regras de Alerta
Defina quando alertar, seja numa ferramenta ou no seu código:
| Regra | Limite recomendado | Por quê |
|---|---|---|
| API Fora do Ar | 2 checks falhos consecutivos | Evita falsos positivos por problemas de rede transitórios |
| Alta Latência | P95 > 2000ms | Detecta degradação antes de virar uma queda total |
| Taxa de Erro | > 5% dos checks com 5xx | Detecta falhas parciais que não aparecem como downtime |
| Expiração SSL | Certificado expira em < 14 dias | Te dá 2 semanas para renovar |
Como são as notificações
Os alertas chegam formatados com Block Kit do Slack, incluindo: nome do endpoint, URL, código de status HTTP, região de monitoramento, tempo de resposta, timestamp e um botão direto para o incidente, dashboard ou logs. Vale codificar por cor: vermelho para quedas, amarelo para degradação e verde para recuperação.
Anti-Spam: Uma notificação por incidente
Use um modelo de uma notificação por incidente (nos seus scripts, guarde o estado atual e só poste quando ele mudar): 1 alerta quando o incidente começa e 1 notificação de recuperação quando o endpoint volta ao normal. Se sua API ficar fora do ar por 30 minutos, você recebe exatamente 2 mensagens, não 30.