Un health check es una verificación automática que responde a la pregunta «¿este servicio está en condiciones de funcionar?». Lo consultan balanceadores de carga, orquestadores de contenedores y herramientas de monitoreo para decidir si envían tráfico a una instancia, si la reinician o si alertan a alguien.
Como esas decisiones son automáticas, un health check mal diseñado puede causar exactamente el problema que pretende detectar.
Tres preguntas distintas
Es habitual tener un único endpoint /health para todo. Sin embargo, existen al menos tres preguntas diferentes, y mezclarlas genera errores:
| Tipo | Pregunta que responde | Qué debe verificar | Si falla… |
|---|---|---|---|
| Liveness (vida) | ¿El proceso está vivo o quedó bloqueado? | Que el proceso responde. Nada externo. | Se reinicia la instancia. |
| Readiness (preparación) | ¿Puede atender tráfico ahora? | Que terminó de iniciar y sus dependencias imprescindibles están accesibles. | Se deja de enviar tráfico, sin reiniciar. |
| Startup (arranque) | ¿Terminó de iniciar? | Que la carga inicial finalizó. | Se espera; evita reinicios durante arranques lentos. |
El error más peligroso: dependencias en liveness
Imagina que el check de liveness de tu API verifica la conexión a la base de datos. La base de datos tiene un problema de un minuto. Todas las instancias de la API fallan el check y el orquestador las reinicia. Al volver, todas intentan conectarse a la vez a una base de datos que se está recuperando, fallan otra vez y se reinician de nuevo.
Un problema temporal en una dependencia se convirtió en un ciclo de reinicios de todo el servicio. Reiniciar la API no arregla la base de datos.
Liveness debe fallar solo cuando reiniciar el proceso solucionaría el problema: un bloqueo, un estado interno corrupto o memoria agotada. Si la causa está fuera del proceso, no pertenece a liveness.
Qué incluir en readiness
Readiness sí puede verificar dependencias, pero con criterio:
- Incluye solo las dependencias sin las cuales la instancia no puede hacer nada útil, como su propia base de datos.
- No incluyas servicios externos opcionales. Si el servicio de correos está caído, la API puede seguir atendiendo; esa dependencia debería manejarse con degradación, no sacando la instancia de servicio.
- Considera qué pasa si la dependencia es compartida: si todas las instancias fallan readiness al mismo tiempo, el balanceador no tendrá dónde enviar el tráfico. A veces es preferible responder con errores controlados que desaparecer por completo.
| Escenario de falla | Estado Liveness | Estado Readiness | Acción de la infraestructura |
|---|---|---|---|
| Base de datos principal no disponible | OK (200) | Falla (503) | El balanceador aísla la instancia sin reiniciarla hasta que la base de datos se recupere. |
| Proceso bloqueado (deadlock / fuga de memoria) | Falla (503 / timeout) | Falla | El orquestador destruye y crea una instancia limpia para recuperar el servicio. |
| Servicio externo no crítico caído (e.g. envíos) | OK (200) | OK (200) | Tráfico continúa; la aplicación activa modo degradado o cola asíncrona. |
| Arranque con carga de cachés o migraciones | OK (o Startup check activo) | Falla (503) | No recibe tráfico de usuarios hasta completar la inicialización. |
Cómo implementar el check
- Rápido y barato: una consulta simple (por ejemplo,
SELECT 1) en lugar de una consulta de negocio. - Con su propio tiempo de espera: el check no debe quedarse colgado si la dependencia no responde.
- Sin efectos secundarios: no debe escribir datos ni consumir recursos limitados.
- Con resultados en caché por unos segundos si se consulta con mucha frecuencia, para no convertirlo en carga.
- Con códigos HTTP claros: 200 cuando está bien y 503 cuando no.
Un ejemplo de respuesta de readiness:
GET /health/ready
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "ok",
"checks": {
"database": { "status": "ok", "latency_ms": 4 },
"queue": { "status": "ok" }
}
}Seguridad de los endpoints de salud
Un health check detallado puede revelar versiones, nombres de servidores internos o tecnologías utilizadas, información útil para un atacante. Lo recomendable es:
- Exponer públicamente, si hace falta, solo una respuesta mínima («ok» o «no ok»).
- Restringir el detalle a la red interna o a solicitudes autenticadas.
- No incluir nunca cadenas de conexión, credenciales ni datos de usuarios.
Más allá del servidor: monitoreo externo
Los health checks internos dicen si cada pieza funciona, pero no si el usuario puede usar el sistema. Un certificado TLS vencido, un error de DNS o una mala configuración del balanceador no aparecen en un check interno. Por eso conviene complementar con monitoreo sintético: verificaciones desde fuera de tu red que recorren un camino real, como cargar la página de inicio de sesión o consultar un endpoint público.
Salud de las integraciones
En sistemas que sincronizan datos con terceros, un servicio puede estar «vivo» y aun así no estar haciendo su trabajo. Una señal muy útil es la frescura: cuándo fue la última sincronización exitosa o el último webhook recibido. Si una integración que normalmente recibe pagos cada pocos minutos lleva una hora sin recibir ninguno en horario de actividad, algo anda mal, aunque todos los checks den «ok».
Errores frecuentes
- Un único endpoint usado para liveness y readiness a la vez.
- Verificar servicios externos en liveness.
- Checks que siempre responden 200 aunque la aplicación no funcione.
- Checks lentos o sin tiempo de espera propio.
- Exponer información interna en respuestas públicas.
- Confiar solo en checks internos y no monitorear desde fuera.
Lista de verificación
- Liveness solo verifica el propio proceso.
- Readiness verifica únicamente dependencias imprescindibles.
- Los checks tienen tiempo de espera y son livianos.
- El detalle de salud no es público.
- Existe monitoreo sintético externo.
- Las integraciones exponen una señal de frescura.
Preguntas frecuentes
¿Necesito estos checks si no uso contenedores?
Sí. Aunque no haya un orquestador que reinicie instancias, los balanceadores de carga y las herramientas de monitoreo usan health checks para dirigir tráfico y generar alertas.
¿Cada cuánto debe ejecutarse un health check?
Depende de la herramienta y de cuán rápido necesitas detectar problemas. Lo importante es que el check sea liviano para poder ejecutarlo con frecuencia, y que se requieran varios fallos consecutivos antes de actuar, para evitar reacciones a errores aislados.