Tu API se cae a las 2 AM. La primera persona en darse cuenta es un cliente que tuitea al respecto. Para cuando despiertas, hay 30 tickets de soporte y un hilo en Hacker News sobre tu caída.
Esto es lo que pasa cuando no tienes alertas donde tu equipo realmente mira. Y para la mayoría de equipos de ingeniería, ese lugar es Slack.
En este tutorial vas a aprender cómo configurar alertas de Slack para monitoreo de APIs con incoming webhooks (desde una herramienta de monitoreo o desde tus propios scripts), para que te notifiquen sobre caídas, picos de latencia, tasas de error y expiración SSL en el canal donde ya trabajas.
¿Por qué Slack es el mejor canal para alertas de API?
Los ingenieros no revisan email a las 2 AM. No tienen un dashboard de monitoreo abierto 24/7. Pero sí tienen Slack en el teléfono con notificaciones habilitadas para canales específicos.
Slack es donde tu equipo ya se comunica sobre incidentes. Cuando una alerta de API llega a #ops-alerts, el ingeniero de guardia la ve de inmediato, y el resto del equipo tiene contexto completo sin preguntar "¿qué pasó?"
Por eso tus alertas deberían usar Block Kit (el formato de mensajes ricos de Slack), así recibís notificaciones estructuradas y accionables en vez de texto plano.
Paso 1: Crear un Webhook de Slack
Primero necesitas una URL de webhook de Slack:
- Ve a api.slack.com/apps y haz clic en Create New App
- Selecciona From scratch, nombrala "API Alerts" y elige tu workspace
- En la barra lateral, haz clic en Incoming Webhooks y actívalo
- Haz clic en Add New Webhook to Workspace
- Selecciona el canal para alertas (ej:
#ops-alerts) - Copia la URL del webhook generada
https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXXPaso 2: Mandar alertas al webhook
Si usás una herramienta de monitoreo, buscá su integración de Slack o de webhooks: pegá la URL, mandá una notificación de prueba para confirmar que llega al canal correcto y guardá.
Si corrés tus propios checks, mandar una alerta es un solo request HTTP. Incluí un campo text como fallback y los blocks para el mensaje formateado:
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"Guardá la URL del webhook como secreto (variable de entorno, nunca commiteada en el repo).
Paso 3: Configurar Reglas de Alerta
Definí cuándo alertar, sea en una herramienta o en tu código:
| Regla | Umbral recomendado | Por qué |
|---|---|---|
| API Caída | 2 checks fallidos consecutivos | Evita falsos positivos por problemas de red transitorios |
| Alta Latencia | P95 > 2000ms | Detecta degradación antes de que sea una caída total |
| Tasa de Error | > 5% de checks con 5xx | Detecta fallos parciales que no aparecen como downtime |
| Expiración SSL | Certificado expira en < 14 días | Te da 2 semanas para renovar |
Cómo se ven las notificaciones
Las alertas llegan formateadas con Block Kit de Slack, incluyendo: nombre del endpoint, URL, código de estado HTTP, región de monitoreo, tiempo de respuesta, timestamp y un botón directo al incidente, dashboard o logs. Conviene codificarlos por color: rojo para caídas, amarillo para degradación y verde para recuperación.
Anti-Spam: Una notificación por incidente
Usá un modelo de una notificación por incidente (en tus scripts, guardá el estado actual y posteá solo cuando cambia): 1 alerta cuando empieza el incidente y 1 notificación de recuperación cuando el endpoint vuelve a estar sano. Si tu API está caída 30 minutos, recibís exactamente 2 mensajes, no 30.