Uptime & reachability

Validate DNS resolution, TCP connect, TLS handshake, and HTTP response class.

If a site blocks scanner traffic, you can configure your server/CDN to allow one custom header and set it here.

How to use this check

Use this page when you need a fast answer to "is this endpoint reachable for real users right now?" The report follows the same sequence as a browser request, so you can quickly see where failures start.

Step 1
Enter a full URL and run the check from the public internet perspective.
Step 2
Review DNS, TCP, TLS, and HTTP timing separately to isolate bottlenecks.
Step 3
Open related tools for deeper inspection: DNS Lookup, SSL Checker, and Headers Checker.

FAQ

What does it test first?
DNS resolution is tested first, then TCP reachability, TLS handshake, and final HTTP response.
TCP works, but HTTP fails?
This usually means the server is reachable but traffic is blocked by app-level rules, WAF, redirects, or backend errors.
How to read timings?
High DNS time suggests resolver/propagation issues, high TCP/TLS suggests network or handshake overhead, and high HTTP time points to slow application processing.
For redirect-specific debugging, run Redirect Checker and compare hop-by-hop behavior.

Related guides

How to find domain IP and DNS issues quickly

Use DNS and runtime resolution together to pinpoint reachability failures.

Discovered currently not indexed fix checklist

Step-by-step workflow to remove indexing blockers on important URLs.

Improve indexing with sitemap quality and internal links

Practical linking and sitemap structure that improves crawl focus.