Monitorizar una API significa enviarle peticiones reales a intervalos regulares y comprobar que las respuestas son correctas, no solo que el servidor contestó. Una API que devuelve 200 OK con una lista vacía, un mensaje de error en el cuerpo o una respuesta que tarda diez segundos está rota para las apps que dependen de ella, aunque una comprobación sencilla la diera por buena. Este checklist recoge lo que debes configurar para que tus monitores de API detecten los problemas reales.
1. Elige los endpoints
No lo monitorices todo. Monitoriza aquello de lo que dependen tus usuarios y tus integraciones:
Endpoint de salud o de estado, si comprueba dependencias como la base de datos. Un endpoint de salud que devuelve «ok» sin comprobar nada te dice poco.
Autenticación: el endpoint que emite tokens o valida sesiones. Si falla, falla todo.
Endpoints de lectura principales: los que tu app llama en cada pantalla, como listar pedidos u obtener un perfil.
Rutas de escritura críticas: checkout, registro o receptores de webhooks, monitorizados con datos de prueba. Un monitor de flujos ejecuta esa secuencia de llamadas a la API paso a paso, pasa valores como un token o un ID de pedido de un paso al siguiente y mantiene los secretos protegidos.
API de terceros de las que dependes, como proveedores de pago o de envíos, para saber cuándo el problema no es tuyo. La monitorización de terceros de Uptimecheck sigue las páginas de estado de 31 servicios como Klarna, Shopify y Cloudflare, o cualquier página alojada en Statuspage.
2. Define la petición: método, cabeceras y cuerpo
Una comprobación debe parecerse a la petición de un cliente real:
Método: GET para lecturas; POST, PUT o PATCH para los endpoints que los necesiten.
Cabeceras: Accept: application/json, un Content-Type para las peticiones con cuerpo y las cabeceras personalizadas que exija tu API, como una cabecera de versión.
Cuerpo: un payload pequeño y válido para las peticiones POST, por ejemplo una consulta de búsqueda.
Elige peticiones que se puedan repetir sin riesgo cada minuto. Evita los endpoints que crean pedidos reales, envían emails o cobran tarjetas, salvo que uses una cuenta de prueba dedicada.
3. Gestiona la autenticación
La mayoría de las API necesitan credenciales. Opciones:
Basic auth para endpoints protegidos sencillos.
API key o bearer token en una cabecera, por ejemplo Authorization: Bearer <token>.
Crea una cuenta o un token dedicados a la monitorización con permisos de solo lectura. Así limitas el daño si el token se filtra y mantienes el tráfico de monitorización separado en tus logs. Recuerda que los tokens caducan. Un token de larga duración y de solo lectura para la monitorización evita falsas alarmas cuando caduca un token de corta duración.
4. Valida el código de estado
Decide qué códigos de estado cuentan como éxito. Normalmente son 200, 201 o 204, según el endpoint. Ojo con las redirecciones: una API que de repente redirige a una página de login devuelve un 3xx y después un 200 con HTML. Para cualquier app que espere JSON, eso es una caída.
5. Valida el contenido de la respuesta
Aquí es donde se quedan cortas la mayoría de las comprobaciones de API. Verifica que la respuesta contiene algo que solo devolvería una API que funciona:
Un campo que siempre debería estar, como «status»:»ok» o «id».
Un valor conocido de los datos de prueba.
La ausencia de texto de error, como «error».
Con Uptimecheck defines en cada monitor de API los códigos de estado esperados, una palabra clave y comprobaciones JSON, por ejemplo que $.status sea igual a ok o que exista una cabecera, junto con el método, las cabeceras (incluida basic auth o un bearer token) y el cuerpo.
6. Fija umbrales de tiempo de respuesta
En las API, lento es el nuevo caído. Las apps móviles agotan el tiempo de espera y las integraciones reintentan, lo que añade todavía más carga. Registra el tiempo de respuesta en cada comprobación y fija un umbral basado en lo que es normal:
Revisa una semana de tiempos de respuesta para encontrar la referencia.
Fija un umbral de alerta muy por encima de la variación normal, por ejemplo de dos a tres veces el tiempo de respuesta habitual.
Avisa cuando la lentitud se mantiene, no por picos aislados. Una petición lenta es ruido; una racha de ellas es un problema.
En Uptimecheck fijas un límite de respuesta lenta por monitor y recibes una alerta de lentitud cuando tres comprobaciones seguidas lo superan, y otra cuando vuelve a ir rápido.
Comprobar desde más de una región muestra si la lentitud es global o se limita a una ruta de red. Uptimecheck comprueba desde Estocolmo, Londres y Nueva York y desglosa cada tiempo de respuesta en DNS, conexión, TLS, servidor y descarga, para que veas cuándo empieza la lentitud y en qué se va el tiempo.
7. Monitoriza toda la cadena
Una API rara vez falla sola. Añade monitores para aquello de lo que depende:
Certificados SSL del hostname de la API. Un certificado caducado rompe todos los clientes a la vez.
Registros DNS del dominio de la API.
Recursos del servidor como CPU, memoria y disco en los servidores de la API.
Tareas programadas que mantienen los datos al día, con heartbeats.
8. Envía las alertas a las personas adecuadas
Las alertas de API suelen corresponder a los desarrolladores responsables del servicio. Envíalas al canal de chat del equipo y, para las caídas de producción por la noche, a un canal que llegue a un móvil. Usa webhooks para llevar las alertas a tus propias herramientas de gestión de incidencias. Consulta las notificaciones.
9. Automatiza la creación de monitores
Si despliegas servicios nuevos a menudo, crea los monitores como parte del despliegue. La API REST de Uptimecheck (Professional y Business) cubre monitores, ventanas de mantenimiento y actualizaciones de estado, y está documentada en app.uptimecheck.com/docs/api, así que la monitorización puede formar parte de tu pipeline en lugar de ser un paso manual posterior. Un servidor MCP permite a los asistentes de IA hacer lo mismo con una API key.
10. Cuenta a quienes usan tu API qué está pasando
Si otros equipos o clientes desarrollan sobre tu API, dales una página de estado con un componente para la API. Así no tendrán que depurar su propio código mientras dura tu caída.
Errores habituales al monitorizar una API
Comprobar solo el endpoint de salud. Los endpoints de salud suelen pasar mientras fallan los endpoints reales porque una dependencia está caída.
Usar las credenciales de producción de un usuario real. Cuando ese usuario cambia la contraseña o se va, la monitorización se rompe. Usa una cuenta dedicada.
Ignorar el cuerpo. Una página de error HTML con estado 200 pasa una comprobación que solo mira el estado.
Avisar de cada respuesta lenta. Los picos aislados generan ruido y acostumbran al equipo a ignorar las alertas.
Olvidar las dependencias. La API está bien, pero el certificado caducó o el registro DNS cambió.
El checklist
Elige los endpoints: salud, autenticación, lecturas principales, escrituras críticas y las API de terceros clave.
Define el método, las cabeceras y el cuerpo de cada comprobación.
Usa un token dedicado de solo lectura o credenciales de basic auth.
Define los códigos de estado esperados.
Valida el contenido: un campo o un valor que solo devuelve una API que funciona.
Registra el tiempo de respuesta y avisa cuando la lentitud se mantiene.
Comprueba desde más de una región.
Monitoriza el SSL, el DNS, los servidores y las tareas programadas que hay detrás de la API.
Envía las alertas al equipo responsable, con un canal que llegue al móvil para producción.
Crea los monitores a través de la API como parte de los despliegues.
Resumen
Un 200 OK es el principio de una comprobación de API, no el final. Envía peticiones realistas, valida el contenido, vigila el tiempo de respuesta y cubre toda la cadena que hay detrás de la API.
La monitorización de API con métodos, cabeceras y cuerpos personalizados, comprobaciones JSON y alertas de respuesta lenta está incluida en todos los planes de Uptimecheck. Pruébalo gratis durante 14 días, sin tarjeta de crédito.