Health checks de una API: por qué un 200 OK no garantiza que funcione
Publicado el 2026-10-26 por frfrand
Diseñar liveness y readiness checks sin saturar la base de datos
La ruta /health devuelve 200 y todos felices. Pero resulta que PostgreSQL está caído y no se puede crear una sola reserva. Un health check útil debe distinguir «el proceso vive» de «puedo atender tráfico».
Vamos a bajarlo a tierra: qué significa, cómo se prueba y qué pasa cuando lo usás con clientes o información real. La mayoría de los problemas no se arregla con un botón mágico, sino con pasos que podés repetir y medir.
Qué es Health checks de una API y por qué importa
Liveness indica si conviene reiniciar un proceso que no responde; readiness señala si está preparado para recibir solicitudes. Comprobar todas las dependencias en cada liveness puede generar reinicios en cascada cuando falla una base externa.
Una cosa es que una demo funcione cinco minutos y otra es sostener un servicio todos los días. Para eso necesitás límites, permisos, registros de actividad y procedimientos para resolver fallos sin improvisar.
Ejemplo de implementación o diagnóstico
from fastapi import FastAPI
app = FastAPI()
@app.get('/live')
def live():
return {'status': 'alive'}
# /ready debería consultar dependencias necesarias con timeout corto
# y devolver 503 si no puede atender trabajo realEs una referencia didáctica, no una plantilla que debas ejecutar a ciegas en producción. Sustituí los valores de ejemplo, elegí identidades con permisos mínimos y asegurate de que ninguna clave sensible termine en un log o repositorio.
Cómo lo pondría a funcionar
- Creá un endpoint de liveness muy liviano, sin depender de una consulta lenta.
- Diseñá readiness según dependencias críticas para la funcionalidad principal.
- Usá timeouts cortos para no saturar la base durante una incidencia.
- Comprobá qué hace el balanceador ante 503 y cómo se recupera el servicio.
- Añadí monitoreo funcional externo para comprobar operaciones reales, no sólo HTTP 200.
Después de cada paso, verificá un resultado concreto: una acción autorizada, un estado HTTP, una tarea procesada, un costo registrado o una métrica estable. Si algo no funciona, comprobá cuál fue el primer fallo antes de reintentar en bucle.
Un ejemplo que puede aparecer en un proyecto real
Una API de tours responde a /live mientras está levantada, pero /ready devuelve 503 si no puede consultar disponibilidad por PostgreSQL. Eso ayuda a que el sistema no envíe reservas a una instancia que no puede atenderlas.
Si esa aplicación tiene varios clientes, separá contextos y recursos. Es especialmente importante cuando un chatbot o un agente puede consultar datos: la facilidad de conectar herramientas no debe saltarse los límites de privacidad y autorización.
El error más común
No hagas una consulta costosa en cada health check. Si todos los contenedores consultan la base varias veces por segundo, el monitoreo puede convertirse en parte del problema.
Una configuración con buenos valores predeterminados ayuda, pero no elimina la necesidad de pruebas. Para servicios que escriban datos o disparen acciones, contempla reintentos, duplicados y fallos a mitad de camino.
¿Dónde entra ArduMaker?
En aplicaciones alojadas en ArduMaker, combina el estado de servicios con pruebas de salud y monitoreo externo. Un VPS encendido no garantiza que la aplicación cumpla su función.
Con ArduMaker puedes alojar el backend en un VPS, desplegar desde Git, configurar dominio HTTPS y utilizar herramientas de bases, servicios y MCP según el proyecto. Eso facilita reunir operaciones en un entorno, aunque las reglas de negocio y de seguridad siguen siendo responsabilidad del software.
Qué mediría para saber si mejoró
No mediría solo «funciona/no funciona». También revisaría consumo de recursos, errores, tiempos de respuesta o gasto de API, según la funcionalidad. Define una medida de éxito antes del cambio y compara con el mismo escenario después.
Si un dato parece extraño, comprueba la muestra y la ventana temporal. Un promedio puede esconder casos extremos, y una única ejecución exitosa no demuestra que una automatización soporte miles de solicitudes.
Preguntas frecuentes
¿Necesito una infraestructura grande para empezar? No necesariamente. Primero resuelve el problema con una arquitectura simple y mide el punto donde empieza a quedarse corta.
¿Qué pasa si falla el proveedor externo? Necesitas timeouts, política de reintentos y una respuesta útil para el usuario. No asumas que las APIs externas están siempre disponibles.
¿Cómo mantengo el control? Registra eventos importantes, separa permisos y conserva un procedimiento probado para deshacer cambios o recuperar información.
Referencias para seguir
La idea final: automatizar y medir vale la pena cuando también sabes detectar un error, limitar sus efectos y recuperarte.