Website Down Checker

A website down checker tells you whether a site is offline for everyone or only failing on your own connection, which is the first question to answer before you ring your web host or developer. Our tool checks that the domain resolves in DNS, then requests the home page from our server in Germany, outside your network. You see whether it answered, the HTTP status code, how long the response took and whether HTTPS works, with plain advice on what each result means.

How to use the Is it down?

1. 1 Enter the website addressType the domain, such as example.co.uk, or paste the full URL. We check the home page of that host.
2. 2 Run the down checkSign in with your free account and run the check. We look up the domain in DNS and then request the page over HTTPS, falling back to HTTP if HTTPS gets no response.
3. 3 Read the status and timingThe result shows whether the site is up, the HTTP status code, the response time in milliseconds and whether HTTPS worked.
4. 4 Narrow down the causeUse the result to decide whether to look at your own connection, the domain and DNS, the SSL certificate or the hosting server, then check again about ten minutes later, when our cached result expires.

What happens when you check if a website is down

Loading a web page is a chain of steps, and a site can fail at any one of them. The browser looks up the domain in DNS to get an IP address, connects to that server, negotiates TLS for HTTPS, sends the request and waits for the server to build and return a response. Our website down checker follows the same chain and reports where it stops.

First we check that the domain has an A or AAAA record. If it has neither, nobody can reach the site, so we stop and report it as down for everyone. Otherwise we request the home page over HTTPS, following any redirects, with a connection timeout of a few seconds and an overall limit of about 20 seconds. If HTTPS gets no response at all, we try plain HTTP so you can tell an HTTPS problem from a completely offline server.

Reading the result

The main check gives one of five outcomes based on what came back. Two supporting checks then cover speed and HTTPS whenever the server answered at all.

• Up and responding: the final page returned a 2xx or 3xx status after any redirects. The site is working from our location.
• Down, no response: the server did not answer in time or refused the connection. We show the connection error where one is available.
• Down, server error: a 5xx status, meaning the server is reachable but the application or a proxy in front of it is failing.
• Up, but refusing our checker: a 401, 403 or 429 status. The site answered but blocked an automated request, so it is probably fine for people.
• Home page returns another 4xx: the server works but the home page itself is missing or misrouted, for example a 404.
• Response time over 3 seconds is flagged as slow, and a site that only answered over HTTP is flagged because HTTPS links will show visitors an error.

HTTP status codes you are likely to see

Status codes are defined in RFC 9110, and the first digit tells you the class. 2xx means success and 3xx means redirection. 4xx codes are client errors, where the server is saying the request itself cannot be served, and 5xx codes are server errors, where something on the hosting side has gone wrong.

• 500 Internal Server Error: the application crashed, often after a plugin update, a broken .htaccess rule or a PHP version change.
• 502 Bad Gateway: a proxy or CDN in front of the site could not get a valid answer from the origin server behind it.
• 503 Service Unavailable: the server is overloaded, rate limiting or in maintenance mode, as WordPress does briefly during updates.
• 504 Gateway Timeout: the proxy waited too long for the origin, usually because of a slow database or an overloaded server.
• 403 Forbidden: access is refused, by file permissions or by a firewall or bot protection that blocks automated requests.
• 404 Not Found: the server is up but has no page at that address. On a home page this usually means a missing index file or a routing fault.

Down for everyone, or only for you?

If our checker reports the site as up but it will not load for you, the problem is between you and the server. Typical causes are a stale DNS cache on your computer or router after a recent DNS change, a VPN or office firewall blocking the site, a browser extension, or your own broadband connection. Testing from a phone on mobile data with Wi-Fi turned off is the quickest way to confirm.

There is also a less obvious case: a site can be blocked for some regions or networks only. Security services and hosting firewalls sometimes block IP ranges they consider risky, and some UK broadband filters block categories of site. Because we test from a data centre in Germany, a site that geo-blocks non-UK traffic may look down to us while working in Britain. Bear that in mind if your site deliberately restricts visitors by country.

First steps when your own site is down

When the check confirms your site is down for everyone, work from the outside in. Most outages for small UK businesses come down to a handful of causes, and the result tells you where to start.

• Domain does not resolve: check the domain has not expired at your registrar and that its nameservers and A record are in place.
• No response: check your hosting provider's status page and control panel, and whether the account has been suspended for billing or resource limits.
• Server error: look at the error log in your hosting panel and undo the most recent change, such as a plugin, theme, update or deployment.
• Only HTTP works: renew or reissue the SSL certificate, or switch on your host's free certificate if it has lapsed.
• Slow response: look for a heavy plugin, an overloaded shared server or a missing cache, as slow pages also hurt conversions and Core Web Vitals.

Why one check is not uptime monitoring

A down check is a snapshot from one location at one moment, and its result is cached for about ten minutes per site. It is ideal when someone tells you the site is not loading. It will not tell you how often the site goes down overnight, or how long each outage lasts. For that you need regular checks every few minutes with alerts by email or text, and a record of past incidents to show your host if you need to claim against their service level agreement.

It also helps to know what normal looks like. Run the check on a quiet day and note the status code and response time. A site behind a CDN typically answers in a few hundred milliseconds from Germany, while a busy shared hosting server may take one or two seconds. If the same site suddenly takes four or five seconds, that is often the early warning of an outage: a server running out of memory, a database under strain or a traffic spike from bots. Catching it then, by clearing caches, disabling a misbehaving plugin or asking your host to investigate, is far cheaper than dealing with a full outage during a busy trading day.

Keep a short incident note each time the site goes down, with the time, the result of the check and what fixed it. Over a few months that log shows whether problems are random or keep coming back, which is useful evidence if you need to move to a better hosting plan or provider.

Examples you can copy

curl -sI https://www.example.co.uk

curl -so /dev/null -w "dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  first byte %{time_starttransfer}s  status %{http_code}\n" https://www.example.co.uk

nslookup example.co.uk 1.1.1.1
ipconfig /flushdns

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Common mistakes to avoid

Frequently asked questions