Por qué el monitoreo de APIs es diferente#

Tu sitio web puede estar "up" mientras tu API está rota. Los usuarios ven una homepage que carga bien, pero la funcionalidad de la app de la que dependen está completamente inoperativa.

Ejemplo: tu página de checkout carga (el sitio está up ✅), pero la API de pagos falla (el sitio está roto ❌). Los clientes no pueden completar compras. Los ingresos se detienen.

El monitoreo de APIs detecta estos fallos invisibles.

Qué necesita monitoreo de API#

Pasarelas de pago (Stripe, PayPal, Square)
Endpoints de autenticación (login/logout)
APIs de datos (catálogos de productos, datos de usuario)
Webhooks (datos entrantes de terceros)
Endpoints de búsqueda
APIs de subida de archivos

Códigos de estado HTTP en APIs#

Las APIs usan los códigos de estado HTTP de forma distinta a los sitios web:

Sitio web:

200 OK: la página carga
500 Server Error: el sitio está roto

API:

200 OK: la petición tuvo éxito
400 Bad Request: el cliente envió datos incorrectos
401 Unauthorized: la autenticación falló
403 Forbidden: permiso denegado
404 Not Found: el endpoint no existe
429 Too Many Requests: rate limit alcanzado
500+ Server Error: backend roto

Diferencia clave: una API puede devolver 200 OK con un error en el cuerpo JSON.

Ejemplo:

{
  "status": 200,
  "success": false,
  "error": "Payment processing failed"
}

HTTP dice "OK", pero la API en realidad ha fallado. El monitoreo de uptime básico no detecta esto.

Configurar el monitoreo de API#

Paso 1: Identifica los endpoints de API críticos#

Lista cada endpoint de API que sea crítico para tu negocio:

/api/auth/login (los usuarios no pueden iniciar sesión si esto falla)
/api/payments/create (los usuarios no pueden hacer checkout)
/api/users/profile (la app se cae si esto falla)
/webhooks/stripe (los pagos no se registran si esto falla)

Paso 2: Define la validación de respuesta#

Para cada endpoint, decide qué significa "up":

Comprobación básica (estado HTTP):

El endpoint devuelve 200 o 201 = OK

Comprobación intermedia (estado + tiempo de respuesta):

El endpoint devuelve 200 Y responde en menos de 1 segundo

Comprobación avanzada (estado + contenido del body):

El endpoint devuelve 200 Y el cuerpo de la respuesta contiene los datos esperados

Paso 3: Configura la herramienta de monitoreo#

En Nova Uptime:

Añade el dominio: https://api.yourdomain.com
Para cada endpoint crítico, añádelo como un monitor independiente:
- /api/auth/login
- /api/payments/create
- etc.
Configura la validación del body de respuesta si está disponible
Establece umbrales de alerta (2 fallos consecutivos antes de alertar)

Avanzado: validación del body de respuesta#

Algunos endpoints requieren un formato de respuesta específico.

Ejemplo: endpoint de creación de pago

Respuesta esperada:

{
  "success": true,
  "payment_id": "pay_12345",
  "amount": 99.99
}

Configuración del monitoreo:

Comprueba si la respuesta contiene "success": true
Si falta, el endpoint está "roto" aunque el estado HTTP sea 200

El Email Health Checker de Nova Uptime valida bodies de respuesta — el mismo principio se aplica al monitoreo de API.

Tokens de autenticación en el monitoreo de API#

La mayoría de las APIs requieren autenticación. Para monitorizarlas:

Opción 1: crea una API key de prueba

Genera una API key dedicada para el monitoreo
Usa esta key en todas las peticiones de monitoreo
Esta key solo tiene permisos de lectura (no puede modificar datos)
Úsala en la herramienta de monitoreo

Opción 2: endpoint público

Algunas APIs tienen endpoints sin autenticación (health check, status)
Monitoriza esos en su lugar
Ejemplo: GET /api/health (público, sin auth)

Monitoreo de webhooks#

Los webhooks son más complicados. Son entrantes (los recibes, no los envías).

Monitoriza el endpoint que recibe los webhooks:

Ejemplo: Stripe envía un POST a https://yourdomain.com/webhooks/stripe

Cómo monitorizarlo:

Crea un emisor de webhooks de prueba (lanzamiento manual)
Verifica que el endpoint lo acepta y devuelve 200
Comprueba en los logs que el webhook se procesó

O usa monitoreo sintético:

Configura una petición POST sintética al endpoint del webhook
Incluye un payload de prueba
Verifica que se recibe y se procesa

Monitoreo del tiempo de respuesta#

Las APIs no son solo cuestión de estar up o down. También son cuestión de velocidad.

API lenta = API rota (desde la perspectiva del usuario).

Establece umbrales de tiempo de respuesta:

Endpoint de autenticación: < 200 ms
Endpoint de pagos: < 500 ms
Endpoint de búsqueda: < 1000 ms (más complejo)

Si un endpoint tarda 5 segundos en responder, aunque "funcione", los usuarios sufren timeouts y se van.

Consideraciones sobre rate limiting#

Las APIs suelen aplicar rate limit para prevenir abusos.

Problema: tu monitoreo envía una comprobación cada minuto. Con 1.000 monitores, eso son 1.000 peticiones por minuto. Si tu API limita a 100/minuto, el monitoreo se bloquea.

Solución:

Crea una API key separada para el monitoreo (con rate limit alto)
O reduce la frecuencia de comprobación (cada 5 minutos en vez de 1)
O usa un endpoint interno /health que no esté limitado

Errores habituales en el monitoreo de API#

Error 1: monitorizar producción con operaciones destructivas#

No monitorices:

POST /api/users/delete    ← Borra usuarios en cada comprobación
POST /api/billing/charge  ← Cobra a la tarjeta en cada comprobación

Monitoriza operaciones de solo lectura:

GET /api/users/{id}
GET /api/health

Error 2: incluir la autenticación en la URL#

No hagas:

GET /api/endpoint?auth_token=SECRET

Esto deja secretos en los logs. Usa headers en su lugar:

Authorization: Bearer SECRET_TOKEN

Error 3: no probar los endpoints de webhook#

Los webhooks son críticos pero a menudo no se prueban. Tu procesador de webhooks podría estar completamente roto y nunca te enterarías.

Solución: envía webhooks de prueba con regularidad y verifica que se procesan.

Monitorizar dependencias de la API#

Tu API puede depender de servicios externos:

Base de datos (si cae, la API cae)
Cola de mensajes (Redis, RabbitMQ)
Caché (Memcached)
APIs externas (Stripe, Twilio)

Monitorízalas por separado:

Endpoint de health check de la base de datos
Endpoint de estado de la caché
Página de estado de APIs de terceros

Configurar alertas para fallos de API#

Cuando el monitoreo de API detecta un fallo:

La alerta debe incluir:

Qué endpoint falló
Cuál fue el fallo (timeout vs error 500)
Cuándo empezó
Cambios recientes (si están disponibles)

Severidad de la alerta:

Crítica: API de pagos/autenticación (los usuarios están bloqueados)
Alta: API de búsqueda/datos (los usuarios se frustran)
Media: analítica/logging (errores visibles para los usuarios)

Monitoreo de API en Nova Uptime#

Nova Uptime monitoriza el uptime de la API junto con el del sitio web:

Añade tu dominio de API: https://api.yourdomain.com
Configura el monitoreo de endpoints
Recibe alertas por email/Slack
Consulta el historial de incidentes y los tiempos de respuesta
Capturas automáticas de los fallos (para depuración)

Además, monitoreo de salud del email — si tu API envía emails transaccionales, Nova Uptime comprueba automáticamente SPF/DKIM/DMARC en el mismo dashboard.

Resumen#

Lista los endpoints de API críticos
Define qué significa "up" para cada uno (código de estado, tiempo de respuesta, contenido del body)
Crea un monitor para cada uno
Establece umbrales de tiempo de respuesta
Monitoriza dependencias (base de datos, caché, terceros)
Prueba los webhooks con regularidad
Alerta sobre fallos de inmediato

Empieza a monitorizar tu API hoy: Monitoreo de API con Nova Uptime. Incluye uptime + salud del email en el mismo dashboard. 🚀

Monitoreo de uptime para APIs: monitorizar endpoints y webhooks