Skip to content
Bionic Uptime

A client's site times out or refuses to connect: what to do

The name works, but nothing answers, or something slams the door. There is no error page because the server never got as far as sending one. Here is the order we would work in.

1. Which one you have

"Server IP address could not be found" is a different problem: see what to do when a domain does not resolve. A page with a number like 502 or 503 means the server did answer: see what to do about a server error.

2. Make sure it is not just you

Ask from a terminal. This gives up after ten seconds and prints the code and how long the answer took:

curl -sSL --max-time 10 -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com

On Windows, type curl.exe rather than curl, and use NUL instead of /dev/null. Any failure prints 000 as the code. A timeout also prints an error with (28) in it; a refused connection prints (7) and "Failed to connect"; a reset usually prints (35) or (56).

Then try from your phone on mobile data. If the site works there but not from your office, the server may have blocked your own address, often after a few wrong passwords; security tools on shared hosting do this automatically, and the host can unblock it. Or, if the site has just moved host, your office may still have the old address cached. Either way the site itself is fine.

3. Find where it breaks

4. The usual fixes

5. Check the fix

Run the command from step 2 again. It should print 200 and a time well under ten seconds. A site that answers, but in eight or nine seconds, is still in trouble; most visitors leave long before that.

6. Tell the client what happened

They may have tried the site themselves. For example:

The website was not loading for a while because the server it runs on stopped responding. It is back up, and I have checked the main pages are loading normally again.

7. Next time, hear about it first

Bionic Uptime waits ten seconds for every check. No answer in that time is a failed check, even if the page would have loaded later, and so is a refused or reset connection; the email calls both "connection refused". When both of our locations, on two different companies' networks, and a retry agree within 45 seconds, it is confirmed as an outage and each person on that website's alert list gets one email. For a timeout, the email says the checking locations "waited ten seconds without a response"; if they failed in different ways, it says what each one saw. A site whose answer, redirects included, arrives inside ten seconds counts as up, and after its first half hour its page shows how long it usually takes to respond. A failure that has cleared by the retry does not send an outage email. See the exact outage email.

One way we can be wrong: if the client's firewall blocks both of our addresses, you get an outage email while visitors reach the site fine. If it blocks only one, the site shows Status uncertain after five minutes and you get one email saying our two locations disagree, then one more when both can see it again. Never an outage alert. Our two addresses are listed on the page about our checks, so the host can allow them.

3 websites are free, forever, with no card. Looking after several client sites?

Monitor 3 websites free