A client says their site is down, and it works for you

1. Ask exactly what they see

• The words on the screen, or a screenshot. "Down" can mean a timeout, a security warning, an error code, a blank page or a block page from their own network. Each one points somewhere different, and the full checklist sorts them.
• Where they are and what they are on. Office Wi-Fi, home broadband or a phone on mobile data, and which country.
• Whether anyone else can reach it. If it fails for everyone in their office and works on their phone, the problem is between their office and the site.

2. Look from somewhere other than your desk

Your browser may be showing you a copy it saved earlier, and your network may be one the site treats differently. Open the site in a private window. Then turn off Wi-Fi on your phone and load it on mobile data, which is a different network with a different address. From a terminal, this asks the site directly and prints the code it answers with:

curl -sL -o /dev/null -w "%{http_code}\n" https://example.com

On Windows, type curl.exe and use NUL instead of /dev/null. 200 means it answered normally from where you are. That does not prove it answers from where they are.

3. The usual causes

• Their address has been blocked. A security plugin, the host's firewall or a CDN rule can block one address after a few wrong passwords or too many page loads. It blocks everyone behind that address, so a whole office can lose the site while it works on their phones. They usually see 403 Forbidden or a timeout. Ask them for their public address, which any "what is my IP" page shows, and look for it in the security plugin's log or the host's firewall. More on 403 Forbidden.
• A DNS change has not reached them yet. After a move to a new host or a nameserver change, networks keep the old answer for as long as the record's time to live, sometimes a day or more. Their network may still send them to the old server, which may be switched off. Ask them to run nslookup example.com and send you the address it shows, and compare it with the new host's address. If they get the old one, their network still has the old answer saved. Check your own computer's hosts file too: if you pointed it at the new server while moving the site, it works for you and nobody else. More on DNS problems.
• The IPv6 address is wrong. A domain can have two addresses, an older IPv4 one and an IPv6 one, and networks that have IPv6, which include many mobile networks and home broadband, prefer it. After a move, the IPv6 record (the AAAA record) is easy to leave pointing at the old server. If that server still answers, those visitors get the old site, a certificate warning or an error. If nothing answers there, browsers try IPv4 within a fraction of a second, so most visitors never notice, but apps and other servers that call the site may not fall back and time out. Compare the two: curl -4 -sSI https://example.com and curl -6 -sSI https://example.com. If the second cannot connect, check your own network has IPv6 before blaming the site: try it on your phone's hotspot, or look up the record with nslookup -type=AAAA example.com and check it points at the new host. If the AAAA record points at the old server, change it to the new host's IPv6 address, or delete it if the new host has none.
• The certificate is missing a piece. Some browsers and devices fill in a missing intermediate certificate and others do not, so the site can work on your computer and show a security warning on their phone. More on certificate warnings.
• One country, or one region. A firewall or CDN rule that blocks other countries, or a CDN or host having trouble in one region, fails for visitors there and nowhere else. Look for country rules in the security plugin and the CDN, and check the CDN's status page.
• Their own network filters it. Office and school networks, antivirus web protection and some broadband providers block sites they have classed as risky or new. They see a page from the filter, not from the site. Their IT person or the filter's support can unblock it.
• An old copy is being shown. A cache in their browser, on the host or at the CDN can keep showing a broken page after it is fixed, or keep showing a working page to you after it broke. Clear the site's cache in the hosting panel or the CDN, then look again in a private window.

4. Tell the client what happened

Something they can pass on without having to understand it. For example:

The website was working, but the security settings had blocked your office's internet connection after some failed logins. I have unblocked it, and it should load normally for everyone there now.

5. Next time, know which kind it is

Bionic Uptime checks each website from two locations, Chicago and New Jersey, on two different companies' networks. When both locations and a retry agree within 45 seconds that it is down, it is confirmed as an outage and each person on that website's alert list gets one email. When one location can reach the site and the other cannot for more than five minutes, we do not call it down. The website shows Status uncertain and everyone on that alert list gets one email headed "We cannot confirm the status of", marked "(not a downtime alert)", then one more when both locations can see it again, or an ordinary outage email if both agree it is down. That catches the version of this problem that sits between the site and one of our two networks, such as a firewall rule or a routing fault. See the exact outage email.

What we cannot see: both locations are in the United States and connect over IPv4 only, so a block on your client's own office address, a fault on the site's IPv6 address, a block on visitors from other countries, or a filter on one office's network looks fine to us. For those, the client's call is still the first you hear. The reverse can happen too: a firewall that blocks one of our addresses shows as Status uncertain, and one that blocks both would get you an outage email while visitors reach the site fine. Our 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