dev101.io

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.

Loading tool…

How to use Is My Website Alive?

  1. Type a URL or hostname (`example.com` or `https://example.com/specific/path`).
  2. Hit "Check" — DNS resolve + TCP handshake + HTTP HEAD run in under a second.
  3. Read the verdict badge. Green = alive with a 2xx/3xx. Amber = 4xx (alive but client error). Red = 5xx, unreachable, or DNS failure.
  4. For https sites, the SSL card shows subject, issuer, and days until expiry — with an amber warning when <14 days remain.

Is My Website Alive?

Check whether a website is responding. In under a second, you get: DNS resolution → TCP handshake time → HTTP status → SSL certificate details. Run from our server so you can check sites that your home network can't reach (corporate firewalls, geo-blocks, etc.).

What the check does

  1. DNS resolve — we look up your hostname, pick a public IP.
  2. IP safety gate — we refuse private, loopback, link-local, multicast, and reserved ranges. (You can't use this tool to probe your LAN or our cloud metadata.)
  3. TCP handshake — connect to the resolved IP on port 443 (https) or 80 (http), measure latency.
  4. TLS handshake — for https, complete the TLS negotiation and grab the peer certificate.
  5. HTTP HEAD — send a HEAD request against the URL's path. Fall back to GET if the server returns 405/501.
  6. Return it all — one JSON response with verdict, latency numbers, cert details, and server header.

What "alive" means

The verdict badge has three flavors:

  • 🟢 Alive — DNS + TCP + HTTP all succeeded with a 2xx/3xx status.
  • 🟡 4xx — the server is responding but your URL errored client-side (404, 403, etc.). The site IS alive; the path just isn't.
  • 🔴 5xx / Unreachable — server error, TCP failure, DNS failure, or any step returned an error.

Safety rails

Because this tool sends a real TCP connection on your behalf, we protect the shared server from abuse:

  • SSRF protection — all RFC1918, loopback (127.x), link-local (169.254.x), IPv6 ULA, and multicast ranges are blocked. DNS rebinding is prevented by pinning the resolved IP.
  • Rate limits — 20 checks per client per minute, 15 checks per target per minute globally (so a single site can't be DDoS-assisted), 300 checks total per minute.
  • Timeouts — TCP 5s, TLS 5s, HTTP 8s. No slow-loris.
  • No redirects followed — we report what the URL directly returns, not where it eventually lands.

What it doesn't do

  • Doesn't send ICMP ping (we check TCP instead — more useful for "is the website answering", doesn't need root, cleaner abuse profile).
  • Doesn't scan arbitrary ports (put the port in your URL and we'll check that one).
  • Doesn't measure from multiple geographic locations (single-origin checker, not a monitoring service).
  • Doesn't monitor on a schedule (this is a one-shot tool, not Pingdom).

Related

  • DNS Lookup — inspect A/AAAA/MX/TXT records
  • What's My IP? — see your own public IP
  • HTTP Status — decode what a specific status code means
  • URL Parser — break down a URL into its parts

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 / GET against the pinned IP. A single request in, a single result out. No polling, no queues.

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). Second, TCP has to connect on port 443 (or 80 for http://) within 5 seconds. Third, an HTTP HEAD has to come back with a status in the 2xx/3xx range. If any step fails, you see the exact failure reason — "DNS resolved to disallowed range", "TCP timed out", "HTTP 503". If TCP succeeds but HTTP doesn't, we still show the handshake time (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.x.x, ULA, link-local), or any hostname that resolves to one of those. Ports outside the URL's scheme default (so no arbitrary port-scanning — if you want a non-standard port, put it in the URL and we'll check that one only). We also rate-limit heavily per-target (15/min global across all users) so this tool can't be used to DDoS-assist or probe competitors.

Does the SSL check validate the chain?

We report the certificate details — subject, issuer, validity window, days until expiry. We don't reject self-signed or expired certificates (we'd lose the ability to debug exactly those problems). If the cert is expired we flag it in red; if it expires within 14 days we flag it in amber. If you want strict chain validation against a CA bundle, `openssl s_client -connect host:443` is the right tool.

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. This prevents DNS rebinding — 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 closes that gap. You see which IP we used in case the result is surprising (e.g. you expected CDN edge X but got edge Y).

Related tools