Better Fetch
21 / 21 passed

Production capability baseline

Real calls against the deployed Sydney service, measured through the repository's release gate—not synthetic component timings.

Generated 2026-07-12T07:02:41Z · service 0.3.31

Static HTML

59ms

p50 wall time · 3 / 3 passed · gate ≤ 750ms
JSON API

47ms

p50 wall time · 3 / 3 passed · gate ≤ 1,000ms
JavaScript rendered

3,178ms

p50 wall time · 3 / 3 passed · gate ≤ 12,000ms
Screenshot

1,319ms

p50 wall time · 3 / 3 passed · gate ≤ 5,000ms
Warm named session

645ms

p50 wall time · 2 / 2 passed
Duplicate burst

174ms

p50 wall time · 4 / 4 passed · gate ≤ 1,500ms
Cached JSON reuse

35ms

p50 wall time · 3 / 3 passed · gate ≤ 500ms

Methodology

  • Three attempts for static HTML, JSON, rendered JavaScript, screenshots, and cache reuse.
  • A cold/warm named-session pair and four concurrent duplicate requests.
  • Wall time includes the client-to-service network path; engine time is also preserved in the private artifact.
  • Fixtures verify expected content and target status, not merely an HTTP 200 from Better Fetch.
  • Protected-site and residential-routing probes were excluded from this baseline to avoid presenting a small anti-bot sample as universal coverage.

Interpretation

This is a point-in-time regression baseline, not an uptime SLA or a claim that every website behaves like the controlled fixtures. Live web outcomes vary with target behaviour, geography, rendering, and optional routing.

Current health is available on the status page. API fields such as timing_ms, attempts, blocked, and proxy_used expose the outcome of each customer request.