Monitoreo de REST API: Que Trackear y Que Herramientas Usar

Tu REST API esta "arriba." Felicitaciones. Eso no te dice casi nada.

Uptime significa que el servidor responde. No te dice que /api/checkout tarda 4 segundos en vez de 400 milisegundos. No te dice que el 3% de los requests a /api/users devuelven 500. No te dice que tu endpoint mas critico es 10x mas lento en horas pico.

Metrica 1: Uptime — Pero medido bien

Lo que hacen la mayoria: Un servicio externo pinga /api/health cada 60 segundos. Si devuelve 200, la API esta "arriba."

Lo que deberias hacer: Calcular uptime desde datos de requests reales. Si serviste 1,000,000 de requests y 2,000 devolvieron 5xx, tu uptime efectivo es 99.8%.

Metrica 2: Percentiles de latencia — P50, P95, P99

El tiempo de respuesta promedio es mentira. Si 99 requests tardan 50ms y 1 tarda 10 segundos, el promedio es 149ms. Ese numero esconde que el 1% de tus usuarios tiene una experiencia terrible.

• P50 (mediana) — La experiencia tipica. Si tu P50 es 80ms, la mayoria de usuarios esta bien.
• P95 — El 5% mas lento. Captura queries lentas, cold starts y problemas n+1.
• P99 — El 1% peor. Un usuario que hace 100 llamadas tiene 63% de probabilidad de experimentar el P99 al menos una vez.

Targets: P50 bajo 100ms, P95 bajo 500ms, P99 bajo 2 segundos.

Metrica 3: Error rate por endpoint

Un error rate global de 0.5% parece bien. Pero que pasa si todos los errores vienen de un solo endpoint?

// Vista global: 0.5% error rate — parece bien
// Vista por endpoint:
// GET  /api/users     → 0.01% errores  ✅
// POST /api/checkout  → 12.4% errores  🔴  ← Aca estan todos los errores

Que trackear: 4xx rate (errores de cliente — spikes en 400/422 suelen significar un deploy de frontend roto) y 5xx rate (errores de servidor — siempre tu culpa).

Metrica 4: Throughput — Requests por minuto

Throughput combinado con latencia y errores se vuelve diagnostico:

• Throughput sube + latencia sube = Te acercas al limite de capacidad
• Throughput sube + errores suben = Ya pasaste el limite
• Throughput baja + latencia sube = Una dependencia esta lenta

Metrica 5: Deteccion de endpoints lentos

Los umbrales estaticos ("alertar si respuesta > 2 segundos") no funcionan cuando tenes 30 endpoints con rangos normales distintos. La deteccion de endpoints lentos identifica automaticamente que rutas se estan degradando relativo a su propia baseline.

Comparacion de herramientas

Setup en 5 minutos con Nurbak Watch

npm install @nurbak/watch

// instrumentation.ts
import { initWatch } from '@nurbak/watch'

export function register() {
  initWatch({
apiKey: process.env.NURBAK_WATCH_KEY,
  })
}

En 60 segundos despues del primer request, ves cada API route en el dashboard con P50/P95/P99, error rates, throughput y deteccion de endpoints lentos. Alertas por Slack, email o WhatsApp en menos de 10 segundos.

Que hacer despues del setup

1. Semana 1: Observar. No poner umbrales todavia. Dejar que la herramienta establezca baselines.
2. Semana 2: Poner umbrales de P95 por endpoint (2x la baseline es buen punto de inicio).
3. Semana 3: Poner umbrales de error rate. 0.5% para endpoints criticos, 2% para el resto.
4. Continuo: Revisar semanalmente. Buscar tendencias lentas — un P95 que sube 10% por semana va a ser problema en un mes.

Empeza gratis

Nurbak Watch esta en beta y es completamente gratis durante el lanzamiento. Las 5 metricas de esta guia — percentiles de latencia, error rates, throughput, uptime y deteccion de endpoints lentos — trackeadas automaticamente para cada API route.