Is My Website Alive?

Check if a site is up in under a second — TCP handshake, HTTP status, SSL expiry, response time. No install, no account.

Runs online in your browserNo installNo accountFree

Loading tool…

How to use Is My Website Alive?

Type a URL or hostname in the input. `example.com`, `https://example.com/specific/path`, and `https://api.example.com:8443/status` all work. The tool prepends `https://` when no scheme is present.
Hit the "Check" button. DNS resolution, the IP-safety gate, TCP handshake, TLS handshake, and HTTP HEAD run in sequence and return a single JSON result in under a second for healthy sites.
Read the verdict badge at the top. Green "Alive" means every step succeeded with a 2xx/3xx status. Amber "4xx" means the server responded with a client error — the site is alive, the path is not. Red "Unreachable" or "5xx" means something went wrong, and the exact failure is printed in the relevant card.
Check the TCP card for handshake latency in milliseconds, plus the IP address and IP family (v4 or v6) we actually connected to. If this number is surprisingly high your routing is the first thing to look at, before assuming the app itself is slow.
Check the HTTP card for status code, status text, the `Server` response header, the HTTP method we used (HEAD, or GET if the server rejected HEAD with 405 or 501), and HTTP latency separately from the TCP number.
For HTTPS sites, read the SSL certificate card — common name, issuer, valid-from, valid-to, and days remaining. Amber appears when fewer than 14 days remain; red appears if the certificate is already expired.
Look at the Request Target card to confirm we checked the exact URL you intended. Full URL, protocol, and path are echoed back so you can catch typos without rerunning the check.
If the response includes a server note (for example, "HTTP HEAD timed out after 8000ms"), read it beneath the cards — it is the raw error message captured from Node's socket layer, not a translated UX string.

Is My Website Alive?

Check whether a website is responding right now. In under a second you get a full reachability report: DNS resolution, TCP handshake time, TLS handshake and peer certificate, HTTP status code, server header, and total HTTP latency. The check runs from our Node.js backend rather than your browser, so it works for sites your home network cannot reach, and it can inspect peer certificates and open raw TCP sockets — neither of which a browser can do. One URL in, one structured result out.

Why a dedicated uptime / reachability tool

"Is my site down?" is the question every engineer has typed at least once, and the tools that answer it fall into two broken camps. Third-party monitoring services — Pingdom, UptimeRobot, StatusCake — are excellent at ongoing checks but overkill for a one-shot question. Command-line pieces — curl -I, openssl s_client, dig, nc -zv — are correct and fast but require four separate invocations across DNS, TCP, TLS, and HTTP, with output in four formats nobody wants to reconcile at 2am while on-call.

This tool unifies the four into one request and renders the result in a single card grid. The verdict badge gives the short answer. The TCP card gives handshake latency and the IP we connected to. The HTTP card gives status code, server header, and response time with the handshake subtracted. The SSL card gives certificate subject, issuer, and days until expiry. The request-target card echoes back the URL we actually checked so you can catch the "I typed staging instead of production" mistake before you escalate.

The opinionated decisions — TCP instead of ICMP, HEAD instead of GET, no redirects followed, IPs pinned to defeat rebinding, private ranges blocked, self-signed certificates tolerated — all come from the same place: this is a troubleshooting tool, not a synthetic monitor. You want the rawest signal about which layer failed, not a pretty "Everything is fine" screen hiding the detail you need.

What it does

DNS resolution with an IP-safety gate — Node's async resolver runs with a 3-second timeout and we pick the first public IP. Private ranges (10/8, 172.16/12, 192.168/16), loopback (127/8, ::1), link-local (169.254/16 plus the IPv6 equivalent), multicast, and reserved ranges are refused before a socket opens. DNS rebinding is prevented by pinning the resolved IP for the rest of the check.
TCP handshake with latency — for http:// URLs we open a raw net.connect socket to the resolved IP on port 80 (or the explicit port). For https:// we open a tls.connect socket on port 443 with servername set to the original hostname so SNI selects the right certificate. Handshake time is measured in whole milliseconds between the connect call and the connect event.
TLS peer certificate harvest — on successful TLS we call socket.getPeerCertificate(true) and pull out the subject common name, issuer, valid_from, valid_to, and days until expiry. We pass rejectUnauthorized: false so self-signed, expired, and domain-mismatched certs still surface their details; the UI flags expired (red) and <14-days (amber) afterwards.
HTTP HEAD with GET fallback — against the pinned IP we send a HEAD with Host set to the original hostname, the DevToolsBox-SiteCheck/1.0 user agent, and an 8-second timeout. Servers that return 405 or 501 for HEAD automatically retry with GET. We report status code, status text, the Server response header, the method used, and HTTP latency separately from TCP latency.
Verdict classification — 2xx/3xx is green "Alive"; 4xx is amber with the code called out as a client error; 5xx is red as a server error; TCP or DNS failure is red "Unreachable" with the underlying error message. The SSL badge lives next to the verdict and follows the expired/expiring-soon/valid pattern.
Single-origin, single-shot — we do not retry, do not follow redirects, and do not poll. You get one deterministic result for the URL you typed. For multi-region probes or scheduled alerts, reach for a monitoring product instead of a utility tool.
No caching of results — the response carries cache-control: no-store, max-age=0 so your browser never shows a stale verdict, and the server never persists the check.

Under the hood

The tool ships as two halves: a Next.js client (tool.tsx) that owns the form and result cards, and a route handler (/api/site-check) that does the network work on a Node.js runtime. Keeping the work on the server is structural — browsers cannot open raw TCP sockets, read peer certificates, or set Host independently of the destination IP. Node lets us use net.connect, tls.connect, and http.request / https.request directly and measure each stage with real clocks.

The safety layer runs on every check. resolveAndValidateHost in lib/network-guards.ts resolves the hostname with a timeout and rejects anything matching a reserved range. The first public IP is passed to the connect calls as host, with servername carrying the original hostname for SNI and virtual-host routing. If DNS flips between validation and connect ("DNS rebinding"), the flip has no effect because we never re-resolve.

Rate limiting lives in the same module via MemoryRateLimiter, a three-layer counter keyed by client IP, target hostname, and global traffic. Per-client (20/min) stops one abusive user, per-target (15/min across all clients) stops the tool being used to hammer someone else's site, and global (300/min) caps our outbound fan-out. 429 responses carry a Retry-After header with the exact seconds to wait.

Timeouts are generous but strict. TCP connect: 5 seconds. TLS handshake: 5 seconds. HTTP request: 8 seconds. A check that cannot complete inside the worst-case 18-second window returns an error verdict with the specific stage that stalled.

What's not supported (yet)

Multi-region probing — the check runs from one backend region. If your question is "is it up from Asia?" a single probe is the wrong answer; use a monitoring product with a global probe network.
Scheduled monitoring and alerting — this is a one-shot tool by design. For minute-by-minute polling and PagerDuty integration, reach for UptimeRobot, Better Uptime, or a self-hosted Prometheus Blackbox Exporter.
Redirect following — we report what the URL you typed directly returns, not where it eventually lands. Run a second check on the redirect target if you want that verified.
Full certificate-chain inspection — we surface the leaf certificate subject, issuer, validity window, and days-to-expiry. We do not render intermediates or validate against a CA bundle; openssl s_client -showcerts -connect host:443 -servername host is the canonical tool for that.
Authenticated requests — no Authorization header, cookie, or client certificate. The HEAD we send is always anonymous with a fixed user agent. Authenticated probing is out of scope because one-click tools that store credentials invite abuse.
Arbitrary port scanning — put the port in your URL (https://host.example:8443/) and we check that one port. We will not enumerate a range, and any URL that resolves into a reserved IP range is refused regardless of port.
HTTP/2 and HTTP/3 details — the underlying http.request / https.request use HTTP/1.1. The connection works, but you do not get ALPN, QUIC, or HTTP/2 frame data. For that, curl --http2 -v is the tool of choice.

Related tools

DNS Lookup — if the reachability check fails on the DNS step, the lookup tool gives you the full A, AAAA, MX, NS, and TXT records so you can see whether the hostname is even published.
What's My IP? — confirm you are not hitting a geo-restriction from your current connection before blaming the target site.
HTTP Status — paste the status code you got back (403, 502, 520) and get a plain-English explanation plus the RFC reference.
URL Parser — when the verdict surprises you because of a typo, feed the URL through the parser to see how hostname, port, path, and query decompose.

Frequently asked questions

Is the check run from my browser or from your server?

From our server. Your browser can't open arbitrary TCP sockets or read peer certificates — that requires Node.js on the backend. We receive your URL, resolve the hostname, open a socket to the IP we resolved (not the hostname — that's a DNS-rebinding defense), measure the handshake, and run one HTTP HEAD (or GET if HEAD is rejected) against the pinned IP. A single request in, a single result out. No polling, no queues, no retries.

What does "alive" actually mean here?

Three things in sequence have to succeed. First, DNS has to return a public IP (private/reserved ranges are rejected by network-guards.ts). Second, TCP has to connect on port 443 (or 80 for http://, or whatever port you put in the URL) within 5 seconds. Third, an HTTP HEAD has to come back with a status code. If the status is 2xx or 3xx we show the verdict as green "Alive". If it is 4xx we show amber — the server is up, your URL just errored. If it is 5xx, or TCP fails, or DNS fails, the verdict is red with the exact failure reason. When TCP succeeds but HTTP doesn't we still show the handshake time, which is useful for "the port is open but the app crashed" scenarios.

What can't you check?

Private IPs (your LAN, VPN-only hosts, localhost), cloud-metadata endpoints (169.254.169.254 and friends), IPv6 ULA and link-local ranges, or any hostname that resolves to one of those. Ports outside the URL's scheme default require that you put the port in the URL — we won't port-scan for you. We rate-limit heavily — 20 checks per client per minute, 15 checks per target per minute globally across all users, and 300 checks total per minute across the whole server — so this tool cannot be used to DDoS-assist or probe competitors at scale. Redirects are not followed (we report what the URL you typed directly returns). And there is no scheduled monitoring — this is a one-shot checker, not Pingdom.

Does the SSL check validate the chain?

We report the certificate details — common name, issuer, valid-from date, valid-to date, and days until expiry. We deliberately do NOT reject self-signed or expired certificates because rejecting them would make the tool useless for debugging exactly those problems. If the certificate is already expired we flag it in red; if it expires within 14 days we flag it in amber; otherwise it is green. If you need strict chain validation against a CA bundle, `openssl s_client -connect host:443 -servername host` is the right tool. If you need the full certificate chain including intermediates, grab the PEM with `openssl s_client -showcerts` and read it there.

Why does it show an IP address for the host?

We connect to the resolved IP directly instead of passing the hostname to the socket layer. This prevents DNS rebinding — the classic attack where an attacker's domain resolves to a public IP during validation, then to a private IP by the time we connect. Pinning the IP at validation time closes that gap. You see which IP we used in case the result is surprising (for example, you expected a CDN edge in London but we resolved to one in Frankfurt, or you are debugging a multi-A-record setup and want to know which IP was actually picked).

Why TCP instead of ICMP ping?

ICMP ping tells you whether a machine somewhere in the IP stack is answering. That is rarely what a website operator needs. You need to know whether the specific port that serves your app is open and whether the app on that port is returning useful HTTP. TCP + HTTP answers the real question. ICMP also requires elevated privileges on most hosts (raw sockets) and is frequently blocked or rate-limited by cloud provider firewalls, which produces confusing false negatives. A completed TCP handshake against port 443 is a much stronger signal than a successful ping.

Does a 200 OK actually mean my site works?

Not necessarily. A 200 from HEAD means the server accepted a request for that path and intends to serve a body. It does not mean the HTML renders, the JavaScript bundles load, the database is reachable, or the login flow succeeds. Use this tool as a fast pre-flight — "is the edge up, is the cert valid, is the front door open" — and reserve synthetic browser monitoring (Playwright, Cypress, Datadog Synthetics) for functional checks. If your app returns 200 on `/` even when the backend is down, move your check URL to a dedicated `/healthz` endpoint that actually touches the dependencies you care about.

How accurate are the latency numbers?

They are the wall-clock time between `Date.now()` at the start of the handshake and `Date.now()` when the socket's connect event fires (for TCP) or when the response head fires (for HTTP). They include the network round-trip from our server in New York to your target plus kernel scheduling overhead, so they are reliable relative numbers but not a substitute for a RUM tool that measures from your actual users. If your target is 200ms from NYC and 20ms from Frankfurt, our number is the 200ms figure, and that is a useful upper bound even if your European customers see something faster.