Nova Uptime
Guiasslack-integrationalertsincident-response

Como integrar monitoramento de uptime com o Slack: guia de alertas em tempo real

Configure alertas do Slack para downtime em 10 minutos. Envie incidentes para #alerts e reduza o tempo de resposta de 30 minutos para 60 segundos.

SN
Sumit Nova Uptime
24 de fevereiro de 2026 · 11 min read
Share:

Por que alertas no Slack são melhores que e-mail#

Alertas por e-mail chegam até você... eventualmente. Talvez na sua pasta de promoções. Talvez 30 minutos depois. Talvez você esteja em uma reunião e não cheque o e-mail por 2 horas.

Alertas no Slack chegam ao seu time imediatamente. As notificações aparecem. Seu celular vibra. Seu time vê no canal onde vocês já estão colaborando.

Para problemas críticos de infraestrutura, essa diferença de 1 minuto importa muito.

Exemplo real: uma API de produção cai às 14:00.

  • Alerta por e-mail: enviado às 14:00, chega até você às 14:15 (caixa de entrada cheia), você vê às 14:45
  • Alerta no Slack: enviado às 14:00, a notificação aparece às 14:00, o time responde às 14:02
  • Diferença: 43 minutos mais rápido na resposta ao incidente

Para empresas SaaS, essa diferença de 43 minutos pode custar mais de $30.000 em transações perdidas e confiança dos clientes.

Configurando a integração com o Slack: o guia completo#

Passo 1: Crie um canal no Slack para alertas#

Primeiro, crie um canal dedicado para alertas de monitoramento. Não use #general ou #engineering — os alertas vão se perder.

No Slack:

  1. Clique em "+" ao lado dos canais
  2. Crie o canal: #alerts (ou #incident-alerts, #monitoring, etc.)
  3. Descrição: "Alertas automáticos do monitoramento do site"
  4. Deixe público (para qualquer pessoa poder se inscrever)
  5. Fixe uma mensagem explicando o propósito do canal

Passo 2: Configure a integração com o Slack na sua ferramenta de monitoramento#

Para o Nova Uptime:#

  1. Faça login em go.novauptime.com
  2. Vá em Settings → Integrations
  3. Clique em "Connect Slack"
  4. Clique em "Authorize" (redireciona para o Slack)
  5. Selecione o workspace
  6. Selecione o canal (#alerts)
  7. Clique em "Allow"
  8. Você é redirecionado de volta para o Nova Uptime confirmando a autorização

Para outras ferramentas (Pingdom, Better Stack, UptimeRobot):#

A maioria das ferramentas tem fluxos parecidos:

  1. Settings → Integrations
  2. Encontre "Slack"
  3. Clique em "Add to Slack"
  4. Autorize
  5. Selecione o canal
  6. Confirme

Passo 3: Configure severidade e roteamento dos alertas#

Nem todos os alertas devem ir para #alerts. Alguns devem ir para #critical-incidents, outros para #ops-team.

No Nova Uptime:

  1. Vá nas configurações do domínio
  2. Encontre "Slack Notifications"
  3. Defina o nível de severidade:
    • Critical: vai para #alerts + @menciona o engenheiro de plantão
    • Warning: vai só para #alerts
    • Info: vai só para #ops-internal
  4. Salve

Exemplo de configuração:

Site de e-commerce de produção (critical) → #alerts + SMS para plantão
Servidor de API (critical) → #alerts + SMS para plantão
Wiki interna (info) → #ops-internal
Site de marketing (warning) → #alerts apenas

Passo 4: Personalize as mensagens de alerta#

Os alertas padrão são genéricos. Você quer contexto e itens de ação.

No Nova Uptime:

  1. Configurações do domínio → Slack Message Template
  2. Personalize a mensagem:
🚨 {service_name} está FORA DO AR
Status: {status_code}
Duração: {duration}
Últimas 3 verificações: {recent_checks}

Causas prováveis:
{auto_diagnosis}

Próximos passos:
1. Verificar: ssh app-server-1 && systemctl status nginx
2. Revisar métricas do CloudWatch para pico de CPU/memória
3. Se não resolver após 5 min, acione {oncall_engineer}

Link do Slack para o incidente: {dashboard_link}
  1. Salve o template

Isso é 100x mais útil do que:

Check failed

Passo 5: Teste a integração#

Antes de depender dos alertas no Slack, teste:

Método 1: Alerta manual

  1. A maioria das ferramentas tem o botão "Send Test Alert"
  2. Clique nele
  3. Verifique se a notificação aparece no Slack
  4. Verifique se a mensagem está legível e inclui todos os detalhes

Método 2: Teste real

  1. Pare temporariamente o seu servidor web
  2. Espere 60 segundos pelo alerta
  3. Verifique se a notificação no Slack disparou
  4. Reinicie o servidor
  5. Verifique se a notificação de "recovery" também dispara

O que verificar:

  • ✓ A notificação aparece no canal correto
  • ✓ A mensagem está legível e inclui o nome do serviço
  • ✓ A mensagem inclui informação de status/duração
  • ✓ A mensagem inclui itens de ação
  • ✓ Notificações de recuperação também são enviadas (não só falhas)
  • ✓ As @menções funcionam, se configuradas

Passo 6: Configure threading dos alertas#

Se múltiplos serviços falharem, as threads do Slack mantêm os alertas organizados em vez de inundar o canal.

No Slack:

  1. Vá nas configurações do canal
  2. Encontre "Threading preferences"
  3. Configure como: "Always use threads for replies"
  4. As mensagens vão se organizar em threads em vez de uma lista linear gigante

Resultado:

canal #alerts
├─ 14:00: Site fora do ar (thread: 3 respostas)
│  ├─ Atualização: Investigando
│  ├─ Atualização: Causa raiz encontrada
│  └─ Atualização: Resolvido
├─ 14:15: API lenta (thread: 2 respostas)
│  ├─ Atualização: Escalando instâncias
│  └─ Atualização: Resolvido
└─ 14:30: Entrega de e-mail degradada (thread: 1 resposta)

Muito mais limpo do que 15 mensagens separadas.

Padrões avançados de integração com o Slack#

Padrão 1: @menção em incidentes críticos#

Para incidentes críticos, @mencione automaticamente o engenheiro de plantão.

Configuração:

  1. Crie uma escala de plantão (Google Calendar ou use PagerDuty)
  2. Na ferramenta de monitoramento: vincule à escala de plantão
  3. Quando um incidente crítico disparar, a ferramenta consulta: "Quem está de plantão agora?"
  4. Envia a mensagem no Slack: "@alice Seu site está fora do ar"

Isso garante que a mensagem chegue à pessoa certa imediatamente, em vez de ficar perdida em um canal que ela talvez não esteja acompanhando.

Implementação:

  • Better Stack: integra com escalas do PagerDuty
  • Nova Uptime: integração com Slack com menções de plantão (Pro+)
  • UptimeRobot: requer Zapier ou webhook customizado

Padrão 2: Escada de escalonamento#

Tipos diferentes de alerta precisam de respostas diferentes:

Tier 1: Critical (acionar imediatamente)

Enviar para: #alerts + @on-call-engineer
Formato: 🚨 {service} FORA DO AR
Menção: Sim, marque o engenheiro pelo nome

Tier 2: Warning (investigar nesta hora)

Enviar para: #alerts apenas
Formato: ⚠️ {service} degradado
Menção: Não, deixe o time decidir quem responde

Tier 3: Info (verificar na daily)

Enviar para: #ops-internal apenas
Formato: ℹ️ {metric} em tendência
Menção: sem menção

Configuração dos canais no Slack:

#alerts → para Tier 1 (todo mundo se inscreve)
#ops-internal → para Tier 2/3 (só o time de ops)
#monitoring → para relatórios resumidos (liderança)

Padrão 3: Reações customizadas para status do incidente#

Use reações com emoji do Slack para acompanhar o status do incidente sem poluir a thread:

  • 🚨 = Alerta disparado (padrão)
  • 🔍 = Alguém está investigando
  • 🔧 = Incidente sendo corrigido
  • ✅ = Resolvido
  • 📋 = Post-mortem agendado

Os engenheiros podem reagir à mensagem de alerta original para mostrar o status:

14:00: Site fora do ar 🚨 → 🔍 → 🔧 → ✅
Mostra a evolução do incidente em uma única mensagem

Padrão 4: Integração com rastreamento de incidentes#

Quando um alerta crítico dispara, crie automaticamente um ticket no Jira ou um incidente no incident.io.

Workflow:

Alerta dispara no Nova Uptime
→ Envia para #alerts no Slack
→ Workflow do Slack é acionado
→ Cria automaticamente ticket no Jira
→ Posta o link do Jira na thread
→ O time tem tanto o alerta QUANTO o ticket de rastreamento

Como configurar (Slack Workflows):

  1. Vá nas configurações do canal #alerts
  2. Adicione workflow: "When alert message posted"
  3. Ação: "Create Jira issue"
  4. Mapeie os campos: título do alerta → título no Jira, detalhes do alerta → descrição
  5. Poste o link do Jira de volta no Slack

Padrão 5: Resumo diário/semanal de alertas#

Em vez de receber 50 alertas em #alerts ao longo do dia, receba um resumo.

Configuração:

  1. Ferramenta de monitoramento → Integrations → Slack
  2. Habilite "Daily Digest"
  3. Horário: 17h todos os dias úteis
  4. Canal: #monitoring-digest

Exemplo de resumo:

📊 Resumo de alertas — 20 de fev de 2026

Incidentes críticos: 1
├─ Site fora do ar (14:00–14:05) - RESOLVIDO

Avisos: 3
├─ Tempo de resposta da API lento (várias vezes)
├─ Degradação na entrega de e-mail (2x)
└─ Pico de conexões no banco (1x)

Info: 12 (expirações de domínio, renovações, etc.)

Performance do time:
- MTTR médio (tempo médio de recuperação): 4 min
- Taxa de falsos alarmes: 2%
- Tempo de resposta médio: 1,2s

Isso dá visibilidade para a liderança sem sobrecarregar o time com ruído de alertas.

Erros comuns na integração com o Slack#

Erro 1: Enviar todos os alertas para #general#

Problema: #general já tem 500 mensagens por dia. Os alertas se perdem na hora.

Solução: Crie um canal #alerts dedicado. Faça dele o canal principal de resposta a incidentes do time.

Erro 2: Não testar a integração#

Problema: Você configurou a integração com o Slack semanas atrás. Acontece o primeiro incidente real e nenhum alerta dispara, porque a integração quebrou.

Solução: Teste mensalmente. Dispare alertas de propósito e verifique se a notificação no Slack chega.

Erro 3: Mensagem de alerta vaga demais#

Problema: Notificação no Slack: "Check failed"

  • O time não sabe o que falhou
  • O time não sabe o que fazer
  • Precisa clicar no dashboard para ver os detalhes

Solução: Inclua todos os detalhes na mensagem do Slack:

  • Nome do serviço
  • Código de status
  • Duração
  • Itens de ação
  • Link para o dashboard

Erro 4: Alertas em excesso#

Problema: Receber 50 alertas no Slack por dia → começar a ignorar alertas → perder incidentes reais

Solução: Use thresholds nos alertas. Exija múltiplas confirmações. Só alertas críticos vão para o Slack.

Erro 5: Alertas sem processo de follow-up#

Problema: Alerta dispara, time responde, incidente resolvido. Ninguém documenta o que aconteceu.

Solução: Crie uma rotina pós-incidente:

  1. Incidente é resolvido
  2. Alguém posta na thread: "Post-mortem amanhã às 14h"
  3. Post-mortem acontece
  4. Causa raiz + prevenção são adicionadas ao runbook
  5. Volte para ajustar os alertas

Workflow de resposta a alertas no Slack#

Veja como um time bem ajustado responde:

T+0:00 — Alerta dispara#

🚨 Site fora do ar
Status: HTTP 503
Duração: 30 segundos
Última verificação: 14:00:15

CPU: 95%
Memória: 87%
Conexões ativas: 2.400

➜ SSH para app-server-1
➜ Verificar: top | grep node

T+0:30 — Primeira resposta#

Alice reage com o emoji 🔍 (investigando)

Alice: "Verificando agora... parece que o processo node travou"

T+1:00 — Causa raiz encontrada#

Alice reage com o emoji 🔧 (corrigindo)

Alice: "Memory leak na v3.2.1. Fazendo rollback para v3.2.0"

T+2:00 — Resolvido#

Alice reage com o emoji ✅ (resolvido)

Alice: "Site voltou ao ar. MTTR: 2 minutos"

T+24:00 — Post-mortem#

Alice: "Post-mortem: memory leak no event listener do node.
Corrigido na próxima release. PR: github.com/...
Adicionado alerta para memória acima de 85%"

Esse workflow só é possível se:

  1. O alerta disparar no Slack (chega ao time imediatamente)
  2. O alerta incluir contexto (CPU, memória, códigos de status)
  3. O time souber o que fazer (itens de ação no alerta)
  4. O time documentar aprendizados (evita repetição)

Medindo o sucesso da integração com o Slack#

Após 1 mês, acompanhe:

  1. Velocidade de detecção do alerta: tempo da falha até a notificação no Slack

    • Meta: <60 segundos
  2. Velocidade de resposta do time: tempo da notificação até a resposta

    • Meta: <5 minutos para incidentes críticos
  3. MTTR (tempo médio até a recuperação): tempo do alerta até a resolução

    • Meta: <10 minutos para incidentes críticos
  4. Taxa de falsos alarmes: % de alertas sem problema real

    • Meta: <5%
  5. Confiança nos alertas: pesquise com o time: "Você confia nos alertas de monitoramento?"

    • Meta: 90%+ de "sim"

Se alguma métrica estiver fora, ajuste:

  • Notificação lenta? Verifique a entrega do webhook
  • Resposta lenta? Talvez precise de @menções para alertas críticos
  • Taxa alta de falsos alarmes? Aperte os thresholds
  • Pouca confiança? As mensagens estão muito vagas

Resumo: checklist de integração com o Slack#

  • ✅ Crie o canal #alerts
  • ✅ Conecte a ferramenta de monitoramento ao Slack
  • ✅ Configure roteamento por severidade (critical → @menção, info → #ops-internal)
  • ✅ Personalize as mensagens de alerta com contexto e ações
  • ✅ Teste a integração (dispare um alerta manualmente, verifique a mensagem no Slack)
  • ✅ Configure reações com emoji para acompanhar status
  • ✅ Crie uma rotina de documentação pós-incidente
  • ✅ Acompanhe MTTR e métricas de falsos alarmes
  • ✅ Faça uma verificação mensal da integração
  • ✅ Documente um runbook para cada tipo de alerta

Comece hoje#

Integre seu monitoramento de uptime com o Slack hoje. Leva 10 minutos e economiza incontáveis horas de tempo de resposta a incidentes.

Se você usa o Nova Uptime, vá em Settings → Integrations e clique em "Connect Slack". Você ganha 10 alertas de domínio grátis com verificações de 1 minuto. Sem cartão de crédito.

Seu time não precisa checar 5 dashboards diferentes quando acontecem problemas de infraestrutura. Eles precisam de uma única notificação no Slack que diga exatamente o que está errado e o que fazer.

Monitor Your Website Before It Goes Down

Get uptime monitoring, SSL tracking, domain expiry alerts, and email health checks. Free plan — no credit card required.

Start Monitoring Free

Artigos relacionados