API

Site Monitor API

Trigger and read health crawls, status codes, uptime, and performance tracking over HTTP.

The Site Monitor is Rankion's continuous site-health watchdog: it pings defined URLs at set intervals, runs Lighthouse audits, detects status code changes, downtime, and Core Web Vitals regressions. Through the API you can create monitors, pause them, trigger them manually, and fetch every check result.

Module context: Site Monitor · related: Content Audit.

CRUD

Method	Endpoint	Description
GET	`/v1/site-monitor`	List of all monitors (paginated)
POST	`/v1/site-monitor`	Create new monitor
GET	`/v1/site-monitor/{id}`	Detail including last check + summary
PUT	`/v1/site-monitor/{id}`	Update (URL, interval, alert config)
DELETE	`/v1/site-monitor/{id}`	Delete

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	Description
POST	`/v1/site-monitor/{id}/pause`	Pause monitor (no more checks)
POST	`/v1/site-monitor/{id}/resume`	Reactivate paused monitor
POST	`/v1/site-monitor/{id}/check-now`	Trigger an immediate check (skips the interval)

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

Response: 202 Accepted — the check runs in the background. Result afterwards in /v1/site-monitor/3/checks as the latest row.

Read results

Method	Endpoint	Description
GET	`/v1/site-monitor/{id}/checks`	All check runs (status code, latency, bytes, timestamp)
GET	`/v1/site-monitor/{id}/incidents`	Consolidated incidents (downtime windows, 5xx bursts)
GET	`/v1/site-monitor/{id}/lighthouse`	Lighthouse reports (Performance, SEO, A11y, Best Practices, PWA)

# Last 24 h status code 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}'

Example response for /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}
}

Example /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 run depending on plan every 30–60 min (separate from the HTTP ping). GET /lighthouse returns the time series of the four score categories plus Core Web Vitals (LCP, CLS, INP, TTFB) — the natural data source for an internal performance dashboard.

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

Notes

Interval floor. Monitors cannot run faster than every 60 seconds — even with interval_minutes: 0 set, the scheduler plans on 1 min. check-now is the right answer for spot checks.
Incidents are consolidated server-side. Multiple failed checks within a window are persisted as one incident, not as N individual events.
Lighthouse is costly and runs only when lighthouse_enabled: true is set. The data behind it comes from headless Chrome rendering — on bot blocks (Cloudflare WAF, hCaptcha) the audit returns {error: "blocked"}.
Pause does not abort running jobs. A Lighthouse run already dispatched runs to completion; the pause effect kicks in at the next scheduler tick.
Cross-team IDs return 404 — like most Rankion endpoints.

Related: Articles API · Site Monitor · Content Audit.

Letzte Aktualisierung: May 1, 2026