Alertas y uptime para agentes IA: qué vigilar después del deploy

El healthcheck de deploy confirma que la versión nueva arranca. Railway lo dice explícito: no monitorea el endpoint después de que el deploy está live. A las 3 AM tu proceso muere y nadie te avisa hasta el primer DM de un cliente. Las alertas de uptime cierran ese hueco: algo externo (o la plataforma) te dice que el agente dejó de responder. Las fuentes oficiales fueron consultadas el 3 de septiembre de 2026.

La observabilidad cubre trazas, tokens y calidad del agente. Esta guía cubre disponibilidad del runtime: HTTP 200 en /health, crashes, deploys fallidos y picos de 5xx.

La regla de tres capas

1. Plataforma nativa: Vercel anomaly alerts, Railway webhooks/monitors, Fly service checks.
2. Ping externo: UptimeRobot, Better Stack, cron propio — golpea /health cada 1–5 min desde fuera.
3. Canal humano: Slack o email con runbook de una línea (“revisar logs, luego rollback”).

Si solo tienes capa 1, confías en que la plataforma detecta tu tipo de fallo. Un agente que responde 200 en /health pero devuelve basura al LLM no lo verás aquí — eso es observabilidad de producto.

Vercel: anomaly alerts, no ping

Vercel no hace uptime check clásico cada minuto. Ofrece Anomaly Alerts (Observability Plus en Pro/Enterprise):

• Error anomaly: pico estadístico de 5xx (o 4xx si configuras la regla) en una ruta en 5 minutos vs baseline 24 h.
• Usage anomaly: invocaciones, duración de función o CPU > 4 desviaciones estándar sobre la media de 24 h.

Notificaciones: email, Slack, webhook. Útil cuando /api/webhook empieza a devolver 500 tras un deploy silencioso.

Para un agente en Vercel Functions:

1. Observability → Alerts → regla en la ruta del webhook.
2. Webhook a Slack con enlace directo al deployment.
3. Complemento obligatorio: ping externo a https://tu-dominio.vercel.app/health — Vercel no sustituye esto.

Si el agente solo corre en cron y no tiene tráfico HTTP frecuente, las anomaly de uso pueden no disparar; el cron fallido se ve en logs o en un monitor del propio cron.

Railway: healthcheck ≠ uptime

Railway healthcheck:

• Solo al inicio del deploy — espera HTTP 200 antes de cambiar tráfico.
• Timeout por defecto 300 s (RAILWAY_HEALTHCHECK_TIMEOUT_SEC).
• Requests desde healthcheck.railway.app — añádelo al allowlist si tu framework filtra host.

Para después del deploy:

Mecanismo	Qué cubre	Plan
Project webhooks	Failed, Crashed, alertas de volumen, monitors CPU/RAM	Cualquiera
Monitors en Observability	CPU, RAM, disco, egress — email + in-app + webhook	Pro
Ping externo a /health	Proceso muerto pero sin crash de JVM	Tu cuenta en UptimeRobot/etc.

Railway documenta webhooks con retry (3 intentos, backoff) y timeout 30 s. Trátalos como aviso, no como fuente de verdad — reconcilia con la API si dudas.

Configuración mínima:

1. Settings → Webhooks → URL de Slack incoming o un receiver de 20 líneas.
2. Healthcheck path /health en el servicio del agente (gate de deploy).
3. Monitor de RAM si el agente cachea contexto en memoria (Pro).
4. Ping externo cada 5 min al dominio público del bot.

Fly: service checks vs top-level

Fly distingue checks de servicio (afectan routing) y top-level (solo alerta interna). Un agente HTTP necesita el de servicio en el puerto interno correcto.

Si la Machine cae, Fly puede reiniciar — pero no te manda Slack solo por eso. Combina:

• min_machines_running = 1 si el SLA lo exige (ver cold starts).
• Grace period en el check para no marcar unhealthy durante arranque.
• Ping externo al dominio fly.dev o custom.

Fly no tiene el equivalente a Vercel anomaly out of the box; el ping externo pesa más aquí.

Ping externo: el /health que importa

Tu /health debe:

• Responder 200 en < 1 s.
• No llamar al LLM ni a la base de producción con query pesada.
• Validar lo mínimo: proceso up, variables críticas presentes (sin imprimir valores).

Configura el monitor externo:

• Intervalo 1–5 min (balance costo vs detección).
• Alerta si 2–3 checks seguidos fallan (evita falsos positivos por cold start).
• Notificación a Slack + email de guardia.
• Opcional: monitor separado al webhook path con POST de prueba si el proveedor lo permite.

Railway sugiere el template Uptime Kuma en su marketplace si quieres self-host del monitor — encaja con agentes en VPS Docker.

Errores comunes

Síntoma	Causa	Fix
“Tenía healthcheck” pero nadie supo del outage	Confundir gate de deploy con uptime	Ping externo + webhook Crashed
Alerta cada noche	Cold start + monitor agresivo	2–3 fallos antes de alertar; min_machines_running
/health llama OpenAI	Check lento y caro; falla si la API está caída	Health solo de proceso
Webhook Railway sin HTTPS válido	100 fallos en 6 h → silencio 24 h	Endpoint 2xx en < 30 s
Solo email de Vercel	Nadie lee email a las 3 AM	Slack con @canal

Qué alertar primero (orden)

1. Deploy Failed o Crashed (webhook Railway / revisar dashboard Fly).
2. Ping externo a /health down > 5 min.
3. Vercel error anomaly en ruta del webhook.
4. Railway RAM > 85 % (agente con memoria de sesión).
5. Volumen de disco (sqlite del agente sin rotación).

No alertes “tokens por minuto” en esta capa — eso va en observabilidad de producto.

Relación con el resto

• Preview vs Production: el ping de uptime debe apuntar a Production, no al preview del PR.
• Secretos: el webhook de alertas es otro secret — no lo hardcodees en el repo.
• CI/CD: un deploy verde + healthcheck no reemplaza monitor post-deploy.

Un agente sin alertas es un experimento. El costo de UptimeRobot free tier o un cron en otro servicio es menor que una hora de soporte manual.

Checklist

• /health responde 200 sin LLM (< 1 s)
• Railway: webhook a Slack para Crashed y Failed
• Vercel: anomaly alert en ruta del webhook (si Pro+)
• Ping externo cada 5 min a Production
• Runbook de 3 pasos enlazado en el mensaje de alerta
• Probaste la alerta (apaga el servicio en staging)

La prueba real: para el proceso en staging un martes a las 11:00 y confirma que Slack suena en < 10 min. Si no suena, no tienes alertas — tienes esperanza.

---

Siguiente paso: cuando el agente vuelva, usa logs para la causa raíz. Si el outage fue un deploy malo, rollback. Si todavía no desplegaste, el curso gratuito deja un /health local para practicar antes de cablear Slack.