This is an intelligence module — no score attached, but it captures the fundamentals of whether your site is actually reachable and responding correctly: HTTP status codes, redirect chains, and response time consistency across the scan.
🌿 Beginner — Plain English explanations
Is your site actually up?
This sounds like an obvious question, but "up" isn't always a simple yes/no. A server can respond while returning an error, redirect visitors somewhere unintended, or respond so slowly that it might as well be down. This module captures exactly what happens when a request hits your site — the raw availability facts everything else builds on.
What's being reported
- HTTP status code — the three-digit code your server returns (200 for success, 404 for not found, 500 for server error, and so on), plus its category (2xx/3xx/4xx/5xx) for a quicker read.
- Redirect chains — if your homepage bounces through several redirects before landing on the final page, each hop adds delay and is worth checking for necessity.
- Redirect loops — a specific, clearly-flagged failure mode when a redirect chain cycles back on itself instead of reaching a final destination.
- Response time and rating — how quickly your server responds, bucketed into fast/moderate/slow so the raw number has context.
- DNS resolution time — measured separately from server response time, so a slow DNS lookup and a slow server aren't lumped into one number.
- Consistency check — fires a couple of quick follow-up requests during the same scan to catch intermittent failures a single request can't reveal.
- Rate limit headers (informational only) — checks for
X-RateLimit-*/Retry-After headers the server voluntarily sends. Low reliability signal — this only detects self-reporting, not actual enforcement; absence doesn't mean no rate limiting exists.
Why it matters
A site that's technically "up" but returning a 500 error, looping through unnecessary redirects, or only reliable 8 times out of 10 delivers the same poor experience to a visitor as one that's fully offline. This module exists to surface those in-between failure states that a simple ping check would miss entirely.