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.
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:
- Haz clic en "+" junto a los canales
- Crea el canal: #alerts (o #incident-alerts, #monitoring, etc.)
- Descripción: "Alertas automáticas del monitoring del sitio"
- Hazlo público (para que cualquiera pueda suscribirse)
- 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:#
- Inicia sesión en go.novauptime.com
- Ve a Settings → Integrations
- Haz clic en "Connect Slack"
- Haz clic en "Authorize" (te redirige a Slack)
- Selecciona el workspace
- Selecciona el canal (#alerts)
- Haz clic en "Allow"
- Vuelves a Nova Uptime con la autorización confirmada
Para otras herramientas (Pingdom, Better Stack, UptimeRobot):#
La mayoría de herramientas tienen flujos similares:
- Settings → Integrations
- Busca "Slack"
- Haz clic en "Add to Slack"
- Autoriza
- Selecciona el canal
- 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:
- Ve a la configuración del dominio
- Busca "Slack Notifications"
- 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
- 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:
- Configuración del dominio → Slack Message Template
- 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}
- 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
- La mayoría de herramientas tienen un botón "Send Test Alert"
- Haz clic
- Verifica que la notificación aparece en Slack
- Verifica que el mensaje es legible e incluye todos los detalles
Método de prueba 2: prueba real
- Detén temporalmente tu servidor web
- Espera 60 segundos a que llegue la alerta
- Verifica que la notificación de Slack se dispara
- Reinicia el servidor
- 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:
- Ve a la configuración del canal
- Busca "Threading preferences"
- Configúralo en: "Always use threads for replies"
- 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:
- Crea un calendario de guardias (Google Calendar o usa PagerDuty)
- En la herramienta de monitoring: enlaza el calendario de guardias
- Cuando salta un incidente crítico, la herramienta consulta: "¿Quién está de guardia ahora?"
- 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):
- Ve a la configuración del canal #alerts
- Añade un workflow: "When alert message posted"
- Acción: "Create Jira issue"
- Mapea los campos: título de la alerta → título del Jira, detalles de la alerta → descripción
- 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:
- Herramienta de monitoring → Integrations → Slack
- Activa "Daily Digest"
- Hora: 17:00 cada día laborable
- 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:
- El incidente se resuelve
- Alguien publica en el hilo: "Post-mortem mañana a las 14:00"
- Se hace el post-mortem
- Se añade la causa raíz + prevención al runbook
- 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:
- La alerta llega a Slack (alcanza al equipo de inmediato)
- La alerta incluye contexto (CPU, memoria, códigos de estado)
- El equipo sabe qué hacer (acciones concretas en la alerta)
- El equipo documenta los aprendizajes (evita que se repita)
Medir el éxito de la integración con Slack#
Después de 1 mes, mide:
-
Velocidad de detección de alertas: tiempo desde el fallo hasta la notificación de Slack
- Objetivo: <60 segundos
-
Velocidad de respuesta del equipo: tiempo desde la notificación hasta la respuesta
- Objetivo: <5 minutos para incidentes críticos
-
MTTR (Mean Time to Recovery): tiempo desde la alerta hasta la resolución
- Objetivo: <10 minutos para incidentes críticos
-
Tasa de falsos positivos: % de alertas sin un problema real
- Objetivo: <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 FreeArtículos relacionados
Webhooks e integraciones de monitoring de uptime: crea flujos personalizados
Conecta el monitoring de uptime a tus sistemas mediante webhooks. Guía completa de automatización de incidentes, notificaciones personalizadas y patrones.
Monitorización de dominios con alertas SSL: la guía de configuración completa para 2026
Configura alertas de caducidad de dominio, certificados SSL y uptime en un solo sitio. Stack gratuito con notificaciones por email + WhatsApp. Playbook 2026.
Monitoriza webs con IA usando el MCP Server de Nova Uptime
Conecta Nova Uptime a asistentes de IA como Claude y Cursor mediante MCP. Configura monitoring con IA y comprobaciones de email health en minutos.