Cinco plataformas populares de monitorización de API comparadas en lo que los equipos de verdad evalúan: frecuencia de check, flujos de request multi-paso, plan gratis, integraciones de alertas y coste a escala realista.
| Capacidad | LoadFocus | Pingdom | UptimeRobot | Datadog | New Relic |
|---|---|---|---|---|---|
| Frecuencia mínima de check | 30 segundos | 60 segundos | 60 segundos (1 min) | 30 segundos | 30 segundos |
| Flujos API multi-paso / encadenados | Sí — login + token + call | Add-on Transaction | No | Sí (Synthetic API) | Sí (Synthetic Monitor) |
| Plan gratis con checks de API | Sí — 5 checks gratis | Solo trial | 50 monitores / 5 min | Solo trial | Gratis hasta 100 GB ingest |
| Ubicaciones de check globales | 26+ regiones AWS | 100+ | 13 | 20+ | 20+ |
| Integraciones de alertas (Slack, PagerDuty, webhook) | Sí — los tres | Sí | Sí | Sí | Sí |
| Precio para 50 endpoints @ checks de 1 min | Desde 19 €/mes | Desde 79 $/mes | Desde 7 $/mes (limitado) | Desde 5 $/check/mes | Basado en uso |
El uptime solo no detecta rendimiento degradado. Estas cuatro métricas te dicen si tus APIs están realmente sanas — no solo accesibles.
Tiempo que tarda el 5% más lento de los requests. Las medias esconden la cola larga; el p95 la expone. Un p95 por encima de 500 ms en una API de pago significa usuarios reales esperando más de lo que toleran — y no todos vuelven.
Cuánto tarda la API en enviar el primer byte tras recibir el request. Captura ralentizaciones de DNS, TLS y procesamiento de servidor por separado del transferencia de red. Los picos aquí suelen apuntar al origen, no a la red del cliente.
Porcentaje de checks sintéticos que pasan (status code correcto + forma de response + dentro del presupuesto de latencia). Caídas por debajo del 99% en una API de producción son un incidente alertable, no una curiosidad.
Los checks sintéticos te dicen que la API está arriba; RUM te dice si los clientes reales experimentaron lo mismo. Combina ambos — lo sintético te alerta de caídas, RUM te dice el impacto en cliente.
APIs de producción que mueven ingresos o bloquean otros sistemas: cada 30–60 segundos. APIs internas o de baja criticidad: cada 5 minutos basta. Por debajo de 30 segundos sube el coste sin cazar significativamente más caídas.
El uptime monitoring solo comprueba si el endpoint responde. El API monitoring también valida status codes, forma del body de respuesta, presupuestos de latencia y workflows encadenados (login → token → call). El API monitoring caza las roturas silenciosas que el uptime monitoring no detecta.
Sí — LoadFocus soporta cabeceras, tokens OAuth bearer y requests encadenados donde la respuesta de un paso (un token) se convierte en la auth del siguiente. No hace falta exponer la contraseña de un service account en config plano.
Dentro de un intervalo de check. Con checks de 30 segundos y alertas Slack/PagerDuty, tu on-call recibe el aviso en menos de un minuto. Configura los umbrales de alerta para requerir 2 fallos consecutivos — eso suprime los transitorios de una sola región.
Sí — GraphQL es solo un POST con body JSON, totalmente soportado. gRPC requiere un pequeño adaptador (gRPC-Web o curl sobre h2) — la mayoría de equipos lo envuelven en un proxy REST fino solo para monitorización.
El precio de LoadFocus escala con endpoints × frecuencia. 50 endpoints con checks cada minuto cuestan ~19 €/mes. 500 endpoints con checks cada 30 segundos rondan los 180 €/mes — aproximadamente la mitad de lo que cobran Pingdom o Datadog por cobertura equivalente.
