Monitorización de API

Entérate de que tu API ha dejado de responder antes que tus usuarios

AlertSleep envía la misma petición que envían tus clientes, con cualquier método, tus cabeceras, tu cuerpo y tu token, y comprueba el código de estado y la respuesta. Si falla, una segunda ubicación la repite y recibes un SMS o una llamada.

Empezar prueba de 14 días Ver precios
  • Comprobaciones cada 60 segundos
  • Cada fallo confirmado desde una segunda ubicación
  • SMS y llamadas incluidos
api.example.com
Operativa
GET /health 200 OK · 84 ms
POST /v1/quotes 200 OK · 142 ms
GET /v1/me 200 OK · 97 ms
108 ms
Respuesta media
100%
Disponibilidad, 30 días
60 s
Intervalo de comprobación

Qué puede hacer una comprobación de API

Un monitor es una petición HTTP, configurada tal y como la espera tu API.

Cualquier método, cabeceras y cuerpo

GET, POST, PUT, PATCH, DELETE, HEAD u OPTIONS. Añade tus propias cabeceras y un cuerpo JSON o de formulario a las peticiones POST, PUT y PATCH.

Endpoints con autenticación

Envía un token Bearer o una clave de API en una cabecera, o usa Basic Auth. Las cabeceras y las contraseñas se guardan cifradas.

Tú decides qué es un éxito

Elige qué códigos de estado cuentan como operativo. Todo lo demás es un fallo, y la alerta indica el código que devolvió el servidor.

Comprobación del contenido de la respuesta

Un monitor de palabra clave también lee el cuerpo y falla cuando falta un texto que tú eliges, como "status":"ok". La coincidencia distingue entre mayúsculas y minúsculas.

Confirmación desde una segunda ubicación

Una comprobación fallida se repite al momento desde una segunda ubicación independiente, con el mismo método, cabeceras, cuerpo y credenciales. Si desde allí la petición llega, nadie se despierta.

Tiempos de respuesta y tiempos de espera

Cada comprobación registra el tiempo de respuesta, que se muestra en un gráfico y como media. Fija un tiempo de espera de entre 5 y 60 segundos para que un endpoint que se queda colgado cuente como caído.

Monitores que vale la pena configurar

Seis comprobaciones de API habituales y cómo configurarlas. Sustituye las direcciones de ejemplo por las tuyas.

Endpoint de salud

GET https://api.example.com/health

Operativo si: 200

La comprobación más sencilla y la que más te cuenta. Haz que /health consulte la base de datos y la caché, para que un 200 signifique que la API puede hacer de verdad su trabajo.

POST con cuerpo JSON

POST https://api.example.com/v1/quotes
Content-Type: application/json
{"sku": "TEST-1", "qty": 1}

Operativo si: 200 + "price"

Una petición real que pasa por tu lógica de negocio. Añade tú mismo la cabecera Content-Type y usa un monitor de palabra clave para exigir un campo en la respuesta.

Detrás de autenticación

GET https://api.example.com/v1/me
Authorization: Bearer <token>

Operativo si: 200

Usa un token emitido solo para la monitorización. Un token caducado o revocado devuelve 401, que la comprobación registra como fallo, así que también te enteras cuando fallan las credenciales.

Consulta GraphQL

POST https://api.example.com/graphql
Content-Type: application/json
{"query": "{ health { status } }"}

Operativo si: 200 + "status":"OK"

GraphQL suele responder 200 aunque la consulta falle, y deja el problema en "errors". Con la palabra clave, la comprobación exige los datos que has pedido.

Receptor de webhooks

GET https://shop.example.com/webhooks/payments

Operativo si: 405

Tu endpoint para los webhooks de pagos o envíos solo acepta POST firmados. Añade 405 a los códigos aceptados: si la aplicación responde «método no permitido», está operativa; un tiempo de espera agotado o un 502, no.

Una API de la que dependes

GET https://status.example-provider.com/api/v2/status.json

Operativo si: 200 + "indicator":"none"

Muchos proveedores publican un endpoint de estado en JSON. Vigílalo junto a tu propia API, y cada alerta te dirá si el fallo es tuyo o suyo.

Qué pasa cuando falla una comprobación

  1. 1

    Enviamos tu petición cada 60 segundos

    Desde nuestro servidor, con el método, las cabeceras, el cuerpo y las credenciales que configuras, y comparamos la respuesta con tus reglas.

  2. 2

    Una segunda ubicación la repite

    Si también falla allí, el incidente se abre al momento. Si la segunda ubicación llega a tu API, el fallo está en nuestro lado de la red y no sale ninguna alerta.

  3. 3

    Recibes la alerta con el motivo

    Por SMS, llamada, e-mail o el chat de tu equipo, con el error en el mensaje: el código de estado, el tiempo de espera o la palabra clave que falta.

  4. 4

    Y te avisamos cuando vuelve

    El aviso de recuperación sale con la primera comprobación correcta, y el incidente queda en el historial y en el informe de disponibilidad.

Qué cuenta como caída

La alerta incluye el mensaje que registró la comprobación. Aquí tienes algunos ejemplos.

Un código de estado que no aceptaste

El servidor respondió, pero no con uno de tus códigos: un 500, un 503 del balanceador de carga, un 401 después de que caducara un token.

HTTP 503 Service Unavailable

Falta la palabra clave

El código de estado era correcto, pero el cuerpo no contenía el texto que exige el monitor.

Keyword '"status":"OK"' not found in response

Sin respuesta a tiempo

El endpoint no respondió dentro de tu tiempo de espera, el síntoma más habitual de una API sobrecargada.

Connection failed: cURL error 28: Operation timed out after 30001 milliseconds

Ni siquiera hay conexión

El DNS no resuelve, el puerto está cerrado o la conexión se rechaza.

Connection failed: cURL error 6: Could not resolve host

Un certificado roto

Con la verificación de certificados activada, un certificado caducado, autofirmado o que no coincide hace fallar la comprobación, igual que hace fallar a tus clientes.

Connection failed: cURL error 60: SSL certificate problem

Las alertas y todo lo que las rodea

Monitorizar una API es la mitad del trabajo. La otra mitad es llegar a la persona adecuada y que el trabajo planificado no haga ruido.

Adónde van las alertas

E-mail, SMS y llamadas, además de Slack, Microsoft Teams, Telegram, WhatsApp, Discord y tu propio webhook.
Más información

Ventanas de mantenimiento

Programa una ventana para un despliegue o una migración. Las comprobaciones siguen funcionando, pero no sale ninguna alerta y el tiempo planificado no reduce tu disponibilidad.

Una página de estado para tu API

Publica los monitores en una página de estado pública, para que los desarrolladores que usan tu API la consulten antes de abrir un ticket.
Más información

Nuestra propia API REST

Crea monitores, consulta comprobaciones e incidentes y abre una ventana de mantenimiento desde tu pipeline de despliegue con un token de API.

Tareas en segundo plano

Las colas, las importaciones y las tareas programadas no tienen una petición que podamos enviar. Un monitor de cron espera su ping y te avisa cuando no llega.
Más información

Certificado y dominio

El mismo monitor puede vigilar el certificado de la API y el registro del dominio, y avisarte antes de que caduque cualquiera de los dos.
Más información

Lo que la monitorización de API no hace

Para que lo sepas antes de registrarte, no después.

  • Un monitor envía una sola petición. No hay comprobaciones de varios pasos que inicien sesión, pasen un token a la siguiente petición y validen cada paso.
  • La respuesta se comprueba por el código de estado y, en un monitor de palabra clave, por un texto que debe contener. No hay validación con esquema JSON ni aserciones campo por campo.
  • El tiempo de respuesta se registra, pero no genera alertas. Un endpoint lento solo dispara una alerta cuando supera el tiempo de espera.
  • Las comprobaciones se hacen desde una ubicación y cada fallo se confirma desde una segunda. No es una red de comprobaciones desde muchos países.

¿Necesitas probar un flujo completo?

Intégralo en tu API: un endpoint /health/deep que ejecute el flujo internamente y devuelva 200 o 500. AlertSleep vigila el resultado cada minuto y te avisa en cuanto cambia.

AlertSleep frente a otros servicios para API

El plan de pago más barato de cada servicio: qué puede enviar una comprobación de API y qué canales de alerta incluye.

Función AlertSleep UptimeRobot Better Stack Pingdom
Cabeceras y códigos de estado propios Sí Sí Sí Sí
Palabra clave en la respuesta Sí Sí Sí Sí
Alertas por SMS Incluido Paquetes de créditos Licencia por usuario 50 créditos
Alertas por llamada Sí Paquetes de créditos Licencia por usuario No

Las funciones de la competencia son las de su plan de pago más barato, según se describen en sus propias webs. Consúltalas allí para ver los detalles actuales. (comprobado: octubre 2026)

Comparativas detalladas: AlertSleep vs UptimeRobot · AlertSleep vs Better Stack · AlertSleep vs Pingdom

Preguntas frecuentes

¿Qué es la monitorización de disponibilidad de API?
Un servicio que envía una petición al endpoint de tu API a intervalos fijos y comprueba la respuesta. AlertSleep lo hace cada 60 segundos y te avisa cuando el endpoint devuelve un código de estado que no aceptaste, no responde a tiempo, no es accesible o no incluye una palabra clave que exiges.

¿Puede AlertSleep monitorizar API con autenticación?
Sí. Añade una cabecera Authorization con un token Bearer, una clave de API en cualquier cabecera o credenciales de Basic Auth. Se guardan cifradas y también se envían con la comprobación de confirmación desde la segunda ubicación. AlertSleep no ejecuta un flujo OAuth para obtener un token, así que usa un token de larga duración emitido para la monitorización.

¿Puedo monitorizar peticiones POST y GraphQL?
Sí. Elige POST, PUT o PATCH, pega el cuerpo y añade una cabecera Content-Type. Para GraphQL, envía la consulta como JSON en un POST y usa un monitor de palabra clave para exigir el campo que has pedido, porque GraphQL suele devolver 200 junto con un error.

¿Puede AlertSleep validar la respuesta JSON?
En parte. Un monitor de palabra clave exige un texto en el cuerpo, como "status":"ok", y falla cuando falta. No hay validación con esquema JSON ni aserciones por ruta; si las necesitas, comprueba la respuesta en un endpoint de salud propio y haz que devuelva un código de error.

¿Con qué rapidez detecta AlertSleep una caída de la API?
Las comprobaciones se hacen cada 60 segundos en todos los planes. Un fallo se repite al momento desde una segunda ubicación y, cuando ambas coinciden, la alerta sale de inmediato, así que normalmente te enteras en un minuto o dos.

¿Qué códigos de estado cuentan como fallo?
Tú decides. Por defecto, 200, 201, 202, 204, 301 y 302 cuentan como operativo y todo lo demás como caída. Añade o quita códigos en cada monitor, por ejemplo 405 para un endpoint de webhook que solo acepta POST.

¿Un despliegue disparará alertas?
No, si programas una ventana de mantenimiento para él, en el panel o desde tu pipeline a través de la API de AlertSleep. Las comprobaciones continúan, pero no se envían alertas y la ventana no cuenta en tu disponibilidad.

¿Puedo probar la monitorización de API gratis?
Sí, durante 14 días. Ambos planes empiezan con una prueba de 14 días que incluye la monitorización de API, sin tarjeta. Después de la prueba cuesta desde $59 al año. Para comprobar un único endpoint una vez, la prueba gratuita de tiempo de respuesta no necesita cuenta.

¿Quieres comprobar un endpoint ahora mismo? Haz la prueba gratuita de tiempo de respuesta

Empieza hoy a monitorizar tu API

Configura tu primer endpoint en unos minutos. Pruébalo gratis durante 14 días, sin tarjeta.

Empezar prueba de 14 días Ver precios