Core features

Monitoring

Monitoring is the first implemented Web Fleet capability. Remote HTTP checks, scheduling, health derivation and the SSRF boundary are in the development build now.

HTTP checks

Each site currently receives an HTTP monitor with a target URL, timeout and expected 200-399 response range. Check results retain status, latency, final URL and failure class instead of reducing everything to "down".

{
  "url": "https://example.com/health",
  "interval_seconds": 60,
  "timeout_seconds": 10,
  "expected_status": { "min": 200, "max": 399 },
  "follow_redirects": true
}

Useful failure classification

• DNS resolution failure
• connection refused/unreachable
• TLS handshake or certificate failure
• request timeout
• redirect policy failure
• unexpected HTTP status

From failures to incidents

One failed request does not necessarily make a site down. The current health state machine uses consecutive failures and recovery transitions so intermittent network noise does not become an alert storm.

healthy
  ↓ unexpected HTTP status
degraded

healthy
  ↓ first transport/TLS/DNS-style failure
warning
  ↓ second consecutive failure
down / incident open
  ↓ successful check
healthy / incident closed

SSRF is part of the monitor design

Accepting arbitrary URLs creates a server-side request forgery boundary. The monitor validates destinations, resolved addresses and redirect hops through a shared network guard that rejects private/reserved targets. TLS inspection and crawling reuse the same guarded dialing boundary instead of implementing their own weaker checks.

Scheduling at fleet scale

Checks use bounded concurrency and jitter. TLS and DNS observations are refreshed on lower cadences, and crawling runs on its own six-hour schedule, so expensive website-health work does not piggyback on every uptime check.