Site Monitor

Site Monitor is the continuous health layer over your domains. Instead of auditing once and forgetting, you run a domain in continuous mode: regular crawls, uptime checks, status-code observation, performance-drift detection, and Lighthouse scores. Each monitor has its own lifecycle with pause/resume, manual-check trigger, and incident history. Complementary to Page Deep Audit (one-shot deep analysis) and Content Audit (content-side); Site Monitor is the infrastructure line.

What it can do

• Monitor management — GET/POST /v1/site-monitor lists and creates new monitors. GET/PUT/DELETE /v1/site-monitor/{id} for detail, update, and delete workflow.
• Pause / resume — cleanly stop monitors without deleting them (POST /v1/site-monitor/{id}/pause and .../resume).
• Manual check — POST /v1/site-monitor/{id}/check-now triggers an off-schedule check immediately.
• Check history — GET /v1/site-monitor/{id}/checks lists every crawl with status code, response time, headers.
• Incidents — GET /v1/site-monitor/{id}/incidents shows detected outages and status-code changes with start/end.
• Lighthouse — GET /v1/site-monitor/{id}/lighthouse returns Performance, Accessibility, SEO, and Best Practices scores over time.
• Team scoped — all monitors belong to the current team; cross-team → 404.

When to use

• You run production domains and want immediate notice of status-code drift (200 → 503), redirect loops, or TLS issues.
• You publish content regularly and want to catch performance regressions (Lighthouse score drops) early.
• You need an audit trail: "since when has this URL been down?" → the incident endpoint has the answer.
• You want uptime reports for clients — the check history is the data backbone.

Workflow

1. Create monitor — POST /v1/site-monitor with URL, frequency, and desired checks (HTTP, Lighthouse).
2. Watch checks — the monitor runs autonomously; GET /v1/site-monitor/{id}/checks shows the history.
3. Review incidents — on issues, GET /v1/site-monitor/{id}/incidents returns start, end, status-code transition.
4. Lighthouse drift — GET /v1/site-monitor/{id}/lighthouse shows scores over time; significant drops are a clear refactor trigger.
5. Pause / resume / manual — pause during maintenance; trigger a check-now after deploys to set the new baseline.

For deep single-page diagnosis, switch to Page Deep Audit — that module includes vision analysis, AI renders, and persona evaluation. Site Monitor is the continuous layer; Page Deep Audit is the spot-check.

API

Example body for POST /v1/site-monitor:

{
  "url": "https://rankion.ai",
  "frequency": "hourly",
  "checks": ["http", "lighthouse"]
}

Credits & Limits

• Read & control: all endpoints are credit-free. Site Monitor is a subscription feature, not pay-per-use.
• Frequency caps: typical tiers are hourly/daily/weekly — depending on the plan.
• Lighthouse: mobile profile by default; desktop variant optional.
• Incident threshold: defaults flag 5xx codes, timeouts >30s, and unexpected redirects as incidents.
• Team scoped: cross-team IDs → 404.

Related modules

• Page Deep Audit — spot deep analysis of a single landing page; Site Monitor provides the trigger ("Lighthouse drift detected → start audit").
• Content Audit — content issues (duplicate, thin content); Site Monitor catches infrastructure issues.
• Action Center — todos can be generated from incidents.
• Google Integrations — combined with GSC you see when a status-code issue also leads to crawling drops.