Website Status Checker

About this tool

The Website Status Checker sends an HTTP request to a URL from the UtilityKit server and reports the final HTTP status code with its label, the total response time in milliseconds, the Server header and the full list of response headers. The server sends a HEAD request (retrying as GET when HEAD is refused) and follows up to eight redirects; when the final address differs from what you typed, a “Redirected to” line shows it. Cookie and authorization headers are left out of the header list. This is useful for checking whether an outage is global or local, confirming a deployed site responds, and checking that an http-to-https redirect lands where you expect. Because the request comes from the server, it is independent of your own network and ISP. Only ports 80, 443, 8080 and 8443 are allowed, private addresses are blocked, and the browser stops waiting after 10 seconds.

Why use it

• Checks from the server side — bypasses local network issues for a neutral third-party result.

• Shows the HTTP status code, total response time and response headers in one view.

• Follows redirects and shows the final URL, handy after setting up HTTPS or a new domain.

• No account or browser extension required.

How to use

1. Enter a URL in the Website URL field; https:// is added if you leave out the scheme.
2. Click Check status or press Enter to send the request from the UtilityKit server.
3. Read the status code and label, the response time in milliseconds and the Server value.
4. If a “Redirected to” line appears, check that the final URL is the one you expect.
5. Scroll the response headers table for Content-Type, Cache-Control, Strict-Transport-Security and other headers.

When it helps

• Verifying whether a site outage is local (your network) or global (the actual site is down).
• Confirming a newly deployed site or API endpoint is responding correctly.
• Checking that HTTPS redirects are working after SSL setup or certificate renewal.
• Monitoring service availability during infrastructure changes.

Examples

https://example.com

200 OK
Response time: e.g. 59 ms
Server: cloudflare
Redirected to: https://example.com/
Response headers include content-type: text/html; charset=utf-8 and cf-cache-status: HIT

example.com

Checked as https://example.com, with the same 200 OK result and header list.

https://no-such-host.example

An error message replaces the status cards (for example when DNS lookup fails or the request times out).

Tips

• If status is 200 but the site looks down to you, run a traceroute from your network — the issue is likely between you and the server.
• Response time over 2 seconds may indicate server load or geographic distance — re-run from a closer monitoring location for confirmation.
• 5xx errors usually mean server-side problems (application crash, database down) — check your error logs immediately.
• If you see a long redirect chain (3+ hops), simplify it to one redirect — each extra hop adds latency and risk.
• Cache-Control header reveals CDN behavior — short max-age with public means you have effective edge caching.
• Use HEAD-style checks for monitoring (this tool's default) — they avoid downloading the full body and are gentler on the server.
• For comprehensive uptime monitoring, schedule this check via a cron job or use a dedicated service like UptimeRobot or Pingdom.

Frequently Asked Questions

Glossary

HTTP status code

A three-digit integer in the response status line that classifies the result. 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error.

TTFB

Time-To-First-Byte — the duration from sending a request until the first byte of the response arrives. A core measure of server-side responsiveness, ideally under 200ms.

Redirect chain

A sequence of HTTP redirects (e.g. http → https → www → /path/) before the final response. Each hop adds latency; chains over 3 hops are considered SEO-unfriendly.

Server header

An optional response header revealing the web server software (e.g. nginx/1.25.0, Apache/2.4.58, cloudflare). Often reduced or hidden for security.

TLS handshake

The cryptographic negotiation between client and server that establishes an encrypted HTTPS session. Failures indicate certificate, SNI, or cipher issues.

SNI

Server Name Indication — a TLS extension that lets a client tell the server which hostname it is connecting to, allowing one IP to host multiple HTTPS sites.

Soft 404

A page that returns HTTP 200 but actually says 'not found' in its body. Bad for SEO — search engines penalize sites with soft 404s.

HSTS

HTTP Strict Transport Security — a response header (Strict-Transport-Security) that tells browsers to force HTTPS for all future connections to the host.