Nova Uptime
Guíasslack-integrationalertsincident-response

Cómo integrar la monitorización de uptime con Slack: guía de alertas en tiempo real

Configura alertas de Slack para caídas de sitios web en 10 minutos. Enruta incidentes a #alerts y reduce el tiempo de respuesta de 30 minutos a 60 segundos.

SN
Sumit Nova Uptime
24 de febrero de 2026 · 12 min read
Share:

Por qué las alertas de Slack ganan al email#

Las alertas por email te llegan... tarde o temprano. Quizá en tu carpeta de promociones. Quizá 30 minutos más tarde. Quizá estás en una reunión y no revisas el correo durante 2 horas.

Las alertas de Slack llegan a tu equipo inmediatamente. Aparecen las notificaciones. Tu móvil vibra. Tu equipo las ve en el canal donde ya estáis colaborando.

Para problemas críticos de infraestructura, esta diferencia de 1 minuto importa muchísimo.

Ejemplo real: una API de producción se cae a las 14:00.

  • Alerta por email: enviada a las 14:00, te llega a las 14:15 (bandeja llena), la ves a las 14:45
  • Alerta de Slack: enviada a las 14:00, la notificación aparece a las 14:00, el equipo responde a las 14:02
  • Diferencia: 43 minutos más rápido en la respuesta al incidente

Para empresas SaaS, esta diferencia de 43 minutos puede costar más de $30.000 en transacciones perdidas y confianza del cliente.

Configurar la integración con Slack: la guía completa#

Paso 1: crea un canal de Slack para alertas#

Primero, crea un canal dedicado para las alertas de monitorización. No uses #general ni #engineering: las alertas quedarán enterradas.

En Slack:

  1. Haz clic en "+" junto a los canales
  2. Crea el canal: #alerts (o #incident-alerts, #monitoring, etc.)
  3. Descripción: "Alertas automáticas del monitoring del sitio"
  4. Hazlo público (para que cualquiera pueda suscribirse)
  5. Publica un mensaje fijado que explique el propósito del canal

Paso 2: configura la integración con Slack en tu herramienta de monitoring#

Para Nova Uptime:#

  1. Inicia sesión en go.novauptime.com
  2. Ve a Settings → Integrations
  3. Haz clic en "Connect Slack"
  4. Haz clic en "Authorize" (te redirige a Slack)
  5. Selecciona el workspace
  6. Selecciona el canal (#alerts)
  7. Haz clic en "Allow"
  8. Vuelves a Nova Uptime con la autorización confirmada

Para otras herramientas (Pingdom, Better Stack, UptimeRobot):#

La mayoría de herramientas tienen flujos similares:

  1. Settings → Integrations
  2. Busca "Slack"
  3. Haz clic en "Add to Slack"
  4. Autoriza
  5. Selecciona el canal
  6. Confirma

Paso 3: configura la severidad y el enrutamiento de las alertas#

No todas las alertas deberían ir a #alerts. Algunas deberían ir a #critical-incidents, otras a #ops-team.

En Nova Uptime:

  1. Ve a la configuración del dominio
  2. Busca "Slack Notifications"
  3. Define el nivel de severidad:
    • Critical: va a #alerts + @mention al ingeniero de guardia
    • Warning: va solo a #alerts
    • Info: va solo a #ops-internal
  4. Guarda

Ejemplo de configuración:

Production e-commerce site (critical) → #alerts + SMS to on-call
API server (critical) → #alerts + SMS to on-call
Internal wiki (info) → #ops-internal
Marketing site (warning) → #alerts only

Paso 4: personaliza los mensajes de alerta#

Las alertas por defecto son genéricas. Tú quieres contexto y acciones concretas.

En Nova Uptime:

  1. Configuración del dominio → Slack Message Template
  2. Personaliza el mensaje:
🚨 {service_name} is DOWN
Status: {status_code}
Duration: {duration}
Last 3 checks: {recent_checks}

Probable causes:
{auto_diagnosis}

Next steps:
1. Check: ssh app-server-1 && systemctl status nginx
2. Review CloudWatch metrics for CPU/memory spike
3. If unresolved after 5 min, page {oncall_engineer}

Slack link to incident: {dashboard_link}
  1. Guarda la plantilla

Esto es 100 veces más útil que:

Check failed

Paso 5: prueba la integración#

Antes de depender de las alertas de Slack, pruébalas:

Método de prueba 1: alerta manual

  1. La mayoría de herramientas tienen un botón "Send Test Alert"
  2. Haz clic
  3. Verifica que la notificación aparece en Slack
  4. Verifica que el mensaje es legible e incluye todos los detalles

Método de prueba 2: prueba real

  1. Detén temporalmente tu servidor web
  2. Espera 60 segundos a que llegue la alerta
  3. Verifica que la notificación de Slack se dispara
  4. Reinicia el servidor
  5. Verifica que también se dispara la notificación de "recovery"

Qué verificar:

  • ✓ La notificación aparece en el canal correcto
  • ✓ El mensaje es legible e incluye el nombre del servicio
  • ✓ El mensaje incluye información de estado/duración
  • ✓ El mensaje incluye acciones concretas
  • ✓ Las notificaciones de recuperación también se envían (no solo los fallos)
  • ✓ Las @mentions funcionan si están configuradas

Paso 6: configura los hilos para alertas#

Si fallan varios servicios, los hilos de Slack mantienen las alertas organizadas en lugar de inundar el canal.

En Slack:

  1. Ve a la configuración del canal
  2. Busca "Threading preferences"
  3. Configúralo en: "Always use threads for replies"
  4. Los mensajes se organizarán en hilos en vez de en una lista lineal gigante

Resultado:

#alerts channel
├─ 2:00 PM: Website Down (thread: 3 replies)
│  ├─ Status update: Investigating
│  ├─ Status update: Root cause found
│  └─ Status update: Fixed
├─ 2:15 PM: API Slow (thread: 2 replies)
│  ├─ Status update: Scaling up instances
│  └─ Status update: Resolved
└─ 2:30 PM: Email Delivery Degraded (thread: 1 reply)

Mucho más limpio que 15 mensajes separados.

Patrones avanzados de integración con Slack#

Patrón 1: @mention en incidentes críticos#

Para incidentes críticos, haz @mention automáticamente al ingeniero de guardia.

Configuración:

  1. Crea un calendario de guardias (Google Calendar o usa PagerDuty)
  2. En la herramienta de monitoring: enlaza el calendario de guardias
  3. Cuando salta un incidente crítico, la herramienta consulta: "¿Quién está de guardia ahora?"
  4. Envía el mensaje a Slack: "@alice Your website is down"

Esto garantiza que el mensaje llegue inmediatamente a la persona adecuada, en vez de quedarse enterrado en un canal que quizá no esté mirando.

Implementación:

  • Better Stack: se integra con los calendarios de PagerDuty
  • Nova Uptime: integración con Slack y @mentions de guardia (Pro+)
  • UptimeRobot: requiere Zapier o un webhook personalizado

Patrón 2: escalera de escalado#

Distintos tipos de alerta necesitan respuestas distintas:

Nivel 1: Critical (avisar inmediatamente)

Send to: #alerts + @on-call-engineer
Format: 🚨 {service} DOWN
Mention: Yes, tag the engineer by name

Nivel 2: Warning (investigar esta hora)

Send to: #alerts only
Format: ⚠️ {service} degraded
Mention: No, let team decide who responds

Nivel 3: Info (revisar en la daily)

Send to: #ops-internal only
Format: ℹ️ {metric} trending
Mention: No mention

Configuración de canales en Slack:

#alerts → for Tier 1 (everyone subscribes)
#ops-internal → for Tier 2/3 (ops team only)
#monitoring → for summary reports (leadership)

Patrón 3: reacciones personalizadas para el estado del incidente#

Usa reacciones con emoji de Slack para seguir el estado del incidente sin saturar el hilo:

  • 🚨 = Alerta disparada (por defecto)
  • 🔍 = Alguien está investigando
  • 🔧 = Incidente en proceso de resolución
  • ✅ = Resuelto
  • 📋 = Post-mortem programado

Los ingenieros pueden reaccionar al mensaje original de la alerta para mostrar el estado:

2:00 PM: Website Down 🚨 → 🔍 → 🔧 → ✅
Shows the incident progression in one message

Patrón 4: integración con seguimiento de incidentes#

Cuando salta una alerta crítica, crea automáticamente un ticket en Jira o un incidente en incident.io.

Workflow:

Alert fires in Nova Uptime
→ Sends to Slack #alerts
→ Slack workflow triggers
→ Automatically creates Jira ticket
→ Post Jira link in thread
→ Team has both the alert AND the tracking ticket

Cómo configurarlo (Slack Workflows):

  1. Ve a la configuración del canal #alerts
  2. Añade un workflow: "When alert message posted"
  3. Acción: "Create Jira issue"
  4. Mapea los campos: título de la alerta → título del Jira, detalles de la alerta → descripción
  5. Publica el enlace del Jira de vuelta en Slack

Patrón 5: resumen diario/semanal de alertas#

En lugar de recibir 50 alertas en #alerts durante el día, recibe un resumen.

Configuración:

  1. Herramienta de monitoring → Integrations → Slack
  2. Activa "Daily Digest"
  3. Hora: 17:00 cada día laborable
  4. Canal: #monitoring-digest

Ejemplo de resumen:

📊 Alert Summary — Feb 20, 2026

Critical Incidents: 1
├─ Website Down (2:00-2:05 PM) - RESOLVED

Warnings: 3
├─ API response time slow (multiple times)
├─ Email delivery degradation (2x)
└─ Database connection spike (1x)

Info: 12 (domain expirations, renewals, etc.)

Team Performance:
- Avg MTTR (mean time to recovery): 4 min
- False alarm rate: 2%
- Page response time: 1.2s avg

Esto da visibilidad a la dirección sin saturar al equipo con ruido de alertas.

Errores habituales en la integración con Slack#

Error 1: enviar todas las alertas a #general#

Problema: #general ya tiene 500 mensajes al día. Las alertas se pierden inmediatamente.

Solución: crea un canal #alerts dedicado. Hazlo el canal principal de respuesta a incidentes del equipo.

Error 2: no probar la integración#

Problema: configuraste la integración con Slack hace semanas. Sucede el primer incidente real y no salta ninguna alerta porque la integración está rota.

Solución: prueba mensualmente. Dispara alertas a propósito y verifica que la notificación de Slack llega.

Error 3: mensaje de alerta demasiado vago#

Problema: notificación de Slack: "Check failed"

  • El equipo no sabe qué falló
  • El equipo no sabe qué hacer
  • Hay que hacer clic en el dashboard para obtener detalles

Solución: incluye todos los detalles en el mensaje de Slack:

  • Nombre del servicio
  • Código de estado
  • Duración
  • Acciones concretas
  • Enlace al dashboard

Error 4: alertar demasiado#

Problema: recibes 50 alertas de Slack al día → empiezas a ignorar las alertas → te pierdes incidentes reales

Solución: usa umbrales de alerta. Exige varias confirmaciones. Solo las alertas críticas van a Slack.

Error 5: alertas sin proceso de seguimiento#

Problema: salta la alerta, el equipo responde, el incidente se resuelve. Nadie documenta lo que pasó.

Solución: crea una rutina post-incidente:

  1. El incidente se resuelve
  2. Alguien publica en el hilo: "Post-mortem mañana a las 14:00"
  3. Se hace el post-mortem
  4. Se añade la causa raíz + prevención al runbook
  5. Vuelves a ajustar las alertas

Workflow de respuesta a alertas de Slack#

Así responde un equipo bien afinado:

T+0:00 — Salta la alerta#

🚨 Website Down
Status: HTTP 503
Duration: 30 seconds
Last check: 2:00:15 PM

CPU: 95%
Memory: 87%
Active connections: 2,400

➜ SSH to app-server-1
➜ Check: top | grep node

T+0:30 — Primera respuesta#

Alice reacciona con el emoji 🔍 (investigando)

Alice: "Checking now... looks like node process crashed"

T+1:00 — Causa raíz encontrada#

Alice reacciona con el emoji 🔧 (arreglando)

Alice: "Memory leak in v3.2.1. Rolling back to v3.2.0"

T+2:00 — Resuelto#

Alice reacciona con el emoji ✅ (resuelto)

Alice: "Site is back up. MTTR: 2 minutes"

T+24:00 — Post-mortem#

Alice: "Post-mortem: Memory leak in node event listener.
Fixed in next release. PR: github.com/...
Added alert for memory >85%"

Este workflow solo es posible si:

  1. La alerta llega a Slack (alcanza al equipo de inmediato)
  2. La alerta incluye contexto (CPU, memoria, códigos de estado)
  3. El equipo sabe qué hacer (acciones concretas en la alerta)
  4. El equipo documenta los aprendizajes (evita que se repita)

Medir el éxito de la integración con Slack#

Después de 1 mes, mide:

  1. Velocidad de detección de alertas: tiempo desde el fallo hasta la notificación de Slack

    • Objetivo: <60 segundos
  2. Velocidad de respuesta del equipo: tiempo desde la notificación hasta la respuesta

    • Objetivo: <5 minutos para incidentes críticos
  3. MTTR (Mean Time to Recovery): tiempo desde la alerta hasta la resolución

    • Objetivo: <10 minutos para incidentes críticos
  4. Tasa de falsos positivos: % de alertas sin un problema real

    • Objetivo: <5 %
  5. Confianza en las alertas: pregunta al equipo: "¿Confías en las alertas de monitoring?"

    • Objetivo: 90 % o más responde sí

Si alguna métrica se desvía, ajusta:

  • ¿Notificación lenta? Revisa la entrega del webhook
  • ¿Respuesta lenta? Quizá necesitas @mentions para los críticos
  • ¿Tasa alta de falsos positivos? Aprieta los umbrales
  • ¿Poca confianza? Los mensajes son demasiado vagos

Resumen: checklist de integración con Slack#

  • ✅ Crea el canal #alerts
  • ✅ Conecta la herramienta de monitoring a Slack
  • ✅ Configura el enrutamiento por severidad (critical → @mention, info → #ops-internal)
  • ✅ Personaliza los mensajes de alerta con contexto y acciones
  • ✅ Prueba la integración (dispara una alerta manualmente, verifica el mensaje en Slack)
  • ✅ Configura reacciones con emoji para el seguimiento del estado
  • ✅ Crea una rutina de documentación post-incidente
  • ✅ Mide el MTTR y las métricas de falsos positivos
  • ✅ Revisa mensualmente la salud de la integración
  • ✅ Documenta un runbook para cada tipo de alerta

Empieza hoy mismo#

Integra hoy tu monitorización de uptime con Slack. Lleva 10 minutos y te ahorra incontables horas de respuesta a incidentes.

Si usas Nova Uptime, ve a Settings → Integrations y haz clic en "Connect Slack". Tienes 10 alertas de dominio gratis con checks cada minuto. Sin tarjeta de crédito.

Tu equipo no necesita revisar 5 dashboards distintos cuando surgen problemas de infraestructura. Solo necesita una notificación de Slack que les diga exactamente qué pasa y qué hacer.

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

Artículos relacionados