Check if a website is down

How to check if a website is down

Short answer: request the site from a second place on the internet and compare. This checker asks the site from our server in Amsterdam and shows the status code, the response time and the final URL. If it answers here but not for you, the site is up and the problem sits between you and it: your DNS, your provider or a block.

1. 1Enter the address
   A domain such as example.com or a full URL with a path. Without http:// or https:// the check asks over HTTPS first, the way a browser does, and tries plain HTTP once more if HTTPS cannot connect.
2. 2Read the verdict
   Green means the site answered with a page. Amber means it answered, but with something a visitor would not call working: a bot check, a 404, a login, a certificate warning. Red means no usable answer at all, and the verdict names the step that failed: DNS, the connection, HTTPS, or the application behind the web server.
3. 3Follow the next step
   Every verdict lists what to check next, with a link to the tool or guide for that step: the DNS records, the port, the certificate, the route from Amsterdam, or your own connection.

What each result means

Response time is the whole check: DNS lookup, connection, TLS handshake, every redirect and the page download. The first byte is the time from sending the request to the first byte of the answer on the last step, which mostly measures how fast the application builds the page. A first byte of several seconds on a page that loads at all is a server that is close to its limit.

Down for everyone, or just me?

One location cannot prove that a site is down everywhere, and this checker does not pretend to. What it can tell apart is the useful part: a site that fails from a data centre in Amsterdam is most likely broken for many of its visitors too (unless it blocks data centres or whole countries on purpose), and a site that works from here but not for you is up, with something on your path in the way. The usual suspects, in the order worth checking:

• Your connection. The ping test measures your line to Amsterdam; if that fails too, nothing on the internet is reachable for you right now.
• DNS. Your resolver may hold an old address after the site moved, or a failed lookup. The DNS propagation checker compares twelve public resolvers with the domain’s own name server; then clear your DNS cache.
• Your provider or network. Some providers, schools and company networks block sites or whole categories, and some countries block sites by court order. A site that opens on mobile data or over a VPN but not on your Wi-Fi is blocked on the way.
• The site’s firewall. A firewall can block your address, your network or your country while everyone else gets in. Too many failed logins are a common trigger.
• Your browser. Extensions, an old cached redirect or a stale HSTS entry. A private window rules those out in seconds.

The browser’s own error message narrows it down further, because each one names the step that failed: This site can’t be reached explains them one by one.

Check from a terminal

The same checks work with standard tools. These ran on 21 October 2026 on a Debian 12 machine with curl 7.88.1 and dig 9.18 (output shortened); at that time example.com was served through Cloudflare, which the server and cf-ray headers show.

$ curl -sI https://example.com
HTTP/2 200
content-type: text/html; charset=utf-8
server: cloudflare
cf-cache-status: HIT
cf-ray: a4e30c264b50364a-FRA

$ dig @8.8.8.8 example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7352
;; ANSWER SECTION:
example.com.     300   IN   A   104.20.23.154
example.com.     300   IN   A   172.66.147.243
;; Query time: 3 msec

For a quick yes or no with timings, ask curl for the status code and the times only. -L follows redirects like the checker does, and --max-time stops it from hanging on a server that never answers:

curl -sSL -o /dev/null --max-time 15 \
  -w 'status %{http_code}, first byte %{time_starttransfer}s, total %{time_total}s\n' \
  https://example.com/

If curl reports Could not resolve host, the problem is DNS; Connection refused or a time-out is the server or a firewall; an SSL error is the certificate or the TLS setup. Those map one to one onto the verdicts above. The full set of options is in the curl examples.

When it is your own site that is down

If the site runs on your own VPS or dedicated server, the verdict says where to start. Log in over SSH and look at the service, its log and the two resources that most often run out:

systemctl status nginx            # or apache2, caddy, php8.2-fpm
journalctl -u nginx -n 50 --no-pager
ss -tlnp | grep -E ':(80|443)\b'  # is anything listening?
df -h /                           # a full disk stops databases and logs
free -m                           # memory, and whether swap is exhausted

• Nothing listening: start the web server and read why it stopped (restarting nginx, reading the journal).
• Listening, but the check times out: the firewall. ufw status must allow 80 and 443 (UFW setup).
• A full disk or a process killed for memory: no space left on device and OOM-killed processes.

To hear about the next outage before your visitors do, a self-hosted monitor such as Uptime Kuma checks the site every minute from a second server and alerts you.

Frequently asked