Un /health que no consulta la base de datos está mintiendo

Casi todo sistema en producción termina con un endpoint /health que un panel de monitoreo consulta cada cierto tiempo. El error más común, y el más fácil de cometer sin darse cuenta, es que ese endpoint responda 200 OK con solo comprobar que el proceso sigue corriendo — sin verificar nada de lo que ese proceso en realidad necesita para funcionar.

Un proceso vivo no es lo mismo que un sistema funcionando

Node.js puede seguir respondiendo peticiones HTTP perfectamente aunque la conexión a PostgreSQL se haya caído hace diez minutos. Si el /health solo hace res.send('ok') sin tocar la base de datos, va a seguir devolviendo verde mientras cualquier operación real del sistema —iniciar sesión, guardar un pedido, procesar un pago— está fallando en silencio. El panel de monitoreo, mientras tanto, muestra todo en orden.

Qué debería verificar de verdad

Un health check útil hace al menos una consulta real y barata contra cada dependencia crítica del sistema —típicamente, un SELECT 1 contra la base de datos— y solo devuelve 200 si esa consulta responde a tiempo. Si la base de datos no responde, o tarda más de lo razonable, el endpoint debe devolver 503 Service Unavailable, no un 200 con un mensaje de error en el cuerpo que nadie automatizado va a leer. El código de estado HTTP es lo que un panel de monitoreo revisa primero; el contenido de la respuesta casi nunca se inspecciona con el mismo cuidado.

Por qué esto es una política, no una sugerencia

En AppsSDAR, todo sistema que llega a producción se engancha al panel interno de monitoreo con esta regla fija: el /health tiene que consultar la base de datos y devolver 503 si falla, sin excepción. No es una buena práctica opcional — es la diferencia entre enterarme de un problema en el sistema de un cliente por una alerta automática en minutos, o enterarme porque ese cliente escribe molesto horas después preguntando por qué su sistema no funciona.

Un extra que vale la pena: separar "vivo" de "listo"

En sistemas con más de una dependencia —base de datos, un servicio de pagos, un proveedor de correo— conviene distinguir dos preguntas distintas: si el proceso está vivo (liveness, útil para que el orquestador sepa si reiniciar el proceso) y si el sistema está listo para atender tráfico de verdad (readiness, la que de verdad le importa a un cliente). Mezclarlas en un único endpoint funciona para sistemas simples, pero en cuanto hay varias dependencias externas, separar ambas preguntas evita reinicios innecesarios por un problema que en realidad es de un proveedor externo, no del propio proceso.