Cómo configurar alertas de Slack cuando tu sitio web se cae

Slack es el canal de alertas por defecto para la mayoría de los equipos de ingeniería en 2026. La configuración en sí lleva diez minutos. Hacerlo bien (de modo que el canal sea útil durante un incidente real e ignorable durante una semana tranquila) requiere algo más de reflexión. Esta guía cubre la configuración práctica, las reglas de enrutamiento que evitan el spam de alertas y los pequeños detalles que hacen del canal un lugar agradable en el que convivir durante años.

La configuración en 10 minutos

El patrón estándar utiliza los Incoming Webhooks de Slack. Crea un canal dedicado para alertas (normalmente #alerts o #ops-alerts), añade la aplicación Incoming Webhook, apúntala al canal y pega la URL resultante en tu herramienta de monitorización como un nuevo canal de notificación de Slack.

La mayoría de los monitores de uptime envían entonces un mensaje formateado con el nombre del monitor, el motivo del fallo, el código de estado si procede y un enlace de vuelta al panel. Prueba la integración con un fallo deliberado antes de confiar en ella. Un monitor apuntado a una URL deliberadamente rota es la prueba de extremo a extremo más barata que puedes ejecutar.

Las cuatro reglas de enrutamiento que evitan el spam de alertas

Un canal que recibe una alerta al trimestre enseña a la gente a mirar. Un canal que recibe cincuenta alertas a la semana enseña a la gente a silenciarlo. Cuatro reglas de enrutamiento mantienen honesta la relación entre alerta y señal.

• Alertas con umbral de al menos 3 fallos consecutivos antes de avisar al canal. Una verificación fallida es ruido. Tres seguidas son señal.
• Mensajes de recuperación en el mismo canal que el fallo. Los incidentes resueltos necesitan un mensaje de cierre para que el canal no se quede en rojo para siempre.
• Canales separados para producción y staging. Las alertas de staging van a #ops-staging-alerts; las de producción van a #ops-prod-alerts. La contaminación cruzada mata la señal en ambos.
• Enrutamiento por monitor para los servicios de mayor prioridad. El monitor del checkout de cara al cliente va a un canal separado #ops-incidents que cuenta con un compromiso de guardia más exigente.

El formato de mensaje que realmente ayuda

Los mensajes predeterminados de Slack que envían las herramientas de monitorización suelen estar bien. Las mejoras vienen de una o dos adiciones personalizadas que dan frutos durante un incidente real.

Incluye un enlace al runbook si dispones de uno. Una pequeña línea al final del mensaje de alerta que apunte al runbook de respuesta a incidentes ahorra al ingeniero de guardia noventa segundos a las 3 de la madrugada. Incluye una marca de tiempo «en rojo anteriormente en» si el monitor ha estado oscilando recientemente. Los incidentes repetidos son oro diagnóstico durante un postmortem.

Cuándo Slack no es suficiente

Slack es un canal de chat, no un sistema de paging. Tres modos de fallo no se resuelven simplemente añadiendo alertas a Slack.

• Incidentes nocturnos cuando nadie está leyendo Slack. Una herramienta de paging (PagerDuty, Opsgenie, Better Stack On-Call) debe ir montada sobre el canal de Slack para cubrir las horas fuera de oficina.
• Pérdida de notificaciones móviles. La aplicación móvil de Slack puede acumular notificaciones durante periodos de baja señal. Las alertas críticas necesitan un canal separado que evite Slack por completo.
• Modo silencioso del canal o de concentración. Los propios ajustes de no molestar de Slack silencian las alertas. Una herramienta de paging ignora el no molestar.

Higiene que mantiene útil el canal

Tres pequeños hábitos mantienen un canal de alertas de Slack agradable de usar al cabo de seis meses.

Fija un mensaje con el runbook en la parte superior del canal. Reacciona con un emoji de pulgar arriba cuando se esté investigando una alerta, para que otros lectores sepan que se está gestionando. Realiza una revisión trimestral del volumen de alertas y poda los monitores que generen más ruido que señal. El canal que se limpia cada trimestre se mantiene útil durante años.

Una configuración inicial en 30 minutos

Crea #ops-alerts y #ops-incidents como canales separados. Añade el Incoming Webhook de Slack a cada uno. Conecta tu herramienta de monitorización para que envíe eventos DOWN con un umbral de 3 fallos consecutivos a #ops-alerts. Conecta los monitores de cara al cliente de mayor prioridad a #ops-incidents en su lugar. Añade mensajes de recuperación UP a ambos. Fija un mensaje con el runbook. Pruébalo con un monitor deliberadamente roto. Tiempo total: treinta minutos. Valor total: cada futuro incidente tendrá un historial limpio y fácil de revisar en Slack.