API

API de Site Monitor

Health crawls, status codes, uptime y performance tracking — disparar y leer por HTTP.

El Site Monitor es el watchdog continuo de health de Rankion: pinguea URLs definidas a intervalos fijos, ejecuta auditorías Lighthouse, detecta cambios de status code, downtime y regresiones de Core Web Vitals. Por la API puedes crear monitores, pausarlos, dispararlos manualmente y consultar todos los resultados de check.

Contexto del módulo: Site Monitor · relacionado: Content Audit.

CRUD

Method	Endpoint	Descripción
GET	`/v1/site-monitor`	Lista de todos los monitores (paginada)
POST	`/v1/site-monitor`	Crear nuevo monitor
GET	`/v1/site-monitor/{id}`	Detalle con last check + summary
PUT	`/v1/site-monitor/{id}`	Update (URL, intervalo, alert config)
DELETE	`/v1/site-monitor/{id}`	Eliminar

curl -X POST "$BASE/site-monitor" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "interval_minutes": 5,
    "lighthouse_enabled": true,
    "alert_email": "ops@example.com"
  }'

Control

Method	Endpoint	Descripción
POST	`/v1/site-monitor/{id}/pause`	Pausar monitor (sin más checks)
POST	`/v1/site-monitor/{id}/resume`	Reactivar monitor pausado
POST	`/v1/site-monitor/{id}/check-now`	Disparar check inmediato (omite el intervalo)

# Spot check manual
curl -X POST "$BASE/site-monitor/3/check-now" \
  -H "Authorization: Bearer $TOKEN"

Respuesta: 202 Accepted — el check corre en background. El resultado aparece luego en /v1/site-monitor/3/checks como la fila más reciente.

Leer resultados

Method	Endpoint	Descripción
GET	`/v1/site-monitor/{id}/checks`	Todos los check runs (status code, latencia, bytes, timestamp)
GET	`/v1/site-monitor/{id}/incidents`	Incidents consolidados (ventanas de downtime, bursts 5xx)
GET	`/v1/site-monitor/{id}/lighthouse`	Reportes Lighthouse (Performance, SEO, A11y, Best Practices, PWA)

# Histórico de status codes de las últimas 24h
curl "$BASE/site-monitor/3/checks?from=2026-04-30T00:00:00Z" \
  -H "Authorization: Bearer $TOKEN" \
  | jq '.data[] | {checked_at, status_code, response_ms}'

Ejemplo de response para /checks:

{
  "data": [
    {"id": 9821, "checked_at": "2026-05-01T09:15:00Z", "status_code": 200, "response_ms": 412},
    {"id": 9820, "checked_at": "2026-05-01T09:10:00Z", "status_code": 200, "response_ms": 388},
    {"id": 9819, "checked_at": "2026-05-01T09:05:00Z", "status_code": 503, "response_ms": 12000}
  ],
  "meta": {"total": 1244}
}

Ejemplo /incidents:

{
  "data": [
    {
      "id": 41,
      "started_at": "2026-04-29T14:02:00Z",
      "ended_at": "2026-04-29T14:18:00Z",
      "duration_seconds": 960,
      "status_code": 503,
      "checks_failed": 4,
      "alert_sent": true
    }
  ]
}

Lighthouse

Las auditorías Lighthouse corren a intervalos de 30–60 min según el plan (separadas del HTTP ping). GET /lighthouse devuelve la time series de las cuatro categorías de score más Core Web Vitals (LCP, CLS, INP, TTFB) — la fuente natural para un dashboard interno de performance.

curl "$BASE/site-monitor/3/lighthouse?per_page=30" \
  -H "Authorization: Bearer $TOKEN" \
  | jq '.data[] | {audited_at, performance, seo, lcp_ms, cls}'

Notas

Floor de intervalo. Los monitores no pueden correr más rápido que cada 60 segundos — incluso con interval_minutes: 0 el scheduler planifica a 1 min. check-now es la respuesta correcta para spot checks.
Los incidents se agrupan en servidor. Varios checks fallidos dentro de una ventana se persisten como un incident, no como N eventos individuales.
Lighthouse es caro y solo corre si lighthouse_enabled: true. Los datos los renderiza Headless Chrome — ante bot blocks (Cloudflare WAF, hCaptcha) el audit devuelve {error: "blocked"}.
Pausar no detiene jobs en curso. Un Lighthouse run ya dispatchado termina; el efecto del pause aplica a partir del próximo tick del scheduler.
Los IDs cross-team responden 404 — como en la mayoría de endpoints de Rankion.

Relacionado: API de Artículos · Site Monitor · Content Audit.

Letzte Aktualisierung: 1 de mayo de 2026