Monitorización de API: comprobaciones, aserciones y recorridos de usuario
Monitoriza una API para más que su accesibilidad: verifica la respuesta esperada, detecta ralentizaciones y alerta a las personas adecuadas cuando el contrato falla.
Elige el monitor adecuado
Usa HTTP para un endpoint simple y una comprobación de código de estado. Usa API cuando la solicitud necesite método, cuerpo, encabezados, autenticación o una aserción de respuesta. Usa Browser cuando el éxito dependa de varios pasos visibles para el usuario, como iniciar sesión, navegar o pagar. Usa Heartbeat cuando el sistema que llama sea la mejor prueba de que terminó el trabajo en segundo plano.
Configura una aserción significativa
Empieza con un endpoint estable de salud o preparación. Espera un código de estado específico y, cuando sea útil, un valor pequeño del cuerpo que demuestre que la dependencia está lista. Guarda las credenciales como secretos en la configuración del monitor; nunca pongas credenciales de producción en documentación pública, páginas de estado o código del cliente.
GET https://api.example.com/health
Expected status: 200
Expected body: {"ok":true}Haz aserciones sobre el cuerpo de la respuesta
Un código de estado solo indica que el servidor respondió. La comprobación de palabra clave valida lo devuelto. Introduce una aserción por línea: todas deben coincidir, por lo que varias líneas actúan como Y, no como O. Activa la coincidencia por expresión regular para tratar cada línea como un patrón RE2; sirve para comprobar valores cambiantes. Activa la opción de palabra clave ausente para fallar cuando se encuentre el texto o patrón, por ejemplo una traza de pila o un aviso de error. RE2 no admite lookahead, lookbehind ni referencias inversas, y solo se busca en el primer MB de la respuesta.
# Literal: every line must appear in the body
"status":"ok"
# Regular expression (RE2): every line must match
"status"\s*:\s*"(ok|healthy)"
"version":"4\.[0-9]+"Cuando un endpoint no basta
Una API puede devolver 200 mientras el flujo visible para el cliente sigue fallando. La monitorización de Browser puede validar el recorrido de una persona por la aplicación. Para colas, tareas cron, copias de seguridad y pipelines de despliegue, un heartbeat programado suele ser la señal más fiable porque confirma la finalización, no solo la disponibilidad.
Responde a los fallos de forma deliberada
Envía incidentes a los canales de notificación que tu equipo realmente vigila y añade triggers para acciones seguras de automatizar. Mantén las comprobaciones ruidosas separadas de las que afectan a clientes, para que cada fallo tenga un responsable y una ruta de notificación claras.
Guías relacionadas
La guía de tipos de monitor cubre todas las señales compatibles. La guía de heartbeat contiene ejemplos copiables para cron, workers y GitHub Actions; las notificaciones explican dónde se entregan los incidentes.