API

Site-Monitor-API

Health-Crawls, Statuscodes, Uptime, Performance-Tracking per HTTP triggern und auslesen.

Der Site Monitor ist Rankions kontinuierlicher Site-Health-Watchdog: er pingt definierte URLs in festen Intervallen, fährt Lighthouse-Audits, erkennt Statuscode-Änderungen, Downtime und Core-Web-Vitals-Regressionen. Über die API kannst du Monitore anlegen, pausieren, manuell triggern und alle Check-Resultate abfragen.

Modul-Kontext: Site Monitor · verwandt: Content Audit.

CRUD

Method	Endpoint	Beschreibung
GET	`/v1/site-monitor`	Liste aller Monitore (paginiert)
POST	`/v1/site-monitor`	Neuen Monitor anlegen
GET	`/v1/site-monitor/{id}`	Detail inkl. Last-Check + Summary
PUT	`/v1/site-monitor/{id}`	Update (URL, Intervall, Alert-Config)
DELETE	`/v1/site-monitor/{id}`	Löschen

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"
  }'

Steuerung

Method	Endpoint	Beschreibung
POST	`/v1/site-monitor/{id}/pause`	Monitor pausieren (keine Checks mehr)
POST	`/v1/site-monitor/{id}/resume`	Pausierten Monitor reaktivieren
POST	`/v1/site-monitor/{id}/check-now`	Sofortigen Check triggern (überspringt Intervall)

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

Antwort: 202 Accepted — der Check läuft im Hintergrund. Resultat danach in /v1/site-monitor/3/checks als neueste Zeile.

Resultate auslesen

Method	Endpoint	Beschreibung
GET	`/v1/site-monitor/{id}/checks`	Alle Check-Runs (Statuscode, Latenz, Bytes, Timestamp)
GET	`/v1/site-monitor/{id}/incidents`	Konsolidierte Incidents (Downtime-Fenster, 5xx-Bursts)
GET	`/v1/site-monitor/{id}/lighthouse`	Lighthouse-Reports (Performance, SEO, A11y, Best-Practices, PWA)

# Letzte 24h Statuscode-History
curl "$BASE/site-monitor/3/checks?from=2026-04-30T00:00:00Z" \
  -H "Authorization: Bearer $TOKEN" \
  | jq '.data[] | {checked_at, status_code, response_ms}'

Beispiel-Response für /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}
}

Beispiel /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

Lighthouse-Audits laufen je nach Plan in 30–60 min Abständen (separat vom HTTP-Ping). GET /lighthouse liefert die Zeitreihe der vier Score-Kategorien plus Core-Web-Vitals (LCP, CLS, INP, TTFB) — die natürliche Datenquelle für ein internes Performance-Dashboard.

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

Hinweise

Intervall-Floor. Monitore können nicht schneller als alle 60 Sekunden laufen — selbst wenn interval_minutes: 0 gesetzt wird, plant der Scheduler auf 1 min. check-now ist die richtige Antwort für Spot-Checks.
Incidents werden serverseitig zusammengefasst. Mehrere fehlgeschlagene Checks innerhalb eines Fensters werden als ein Incident persistiert, nicht als N Einzel-Events.
Lighthouse ist costly und läuft nur, wenn lighthouse_enabled: true gesetzt ist. Die Daten dahinter werden Headless-Chrome-rendered — bei Bot-Blocks (Cloudflare-WAF, hCaptcha) liefert der Audit {error: "blocked"}.
Pause beendet keine laufenden Jobs. Ein bereits dispatched Lighthouse-Run rennt durch; der Pause-Effekt wirkt ab dem nächsten Scheduler-Tick.
Cross-Team-IDs liefern 404 — wie bei den meisten Rankion-Endpoints.

Verwandt: Artikel-API · Site Monitor · Content Audit.

Letzte Aktualisierung: 1. Mai 2026