Why Is My Website Down? A Step-by-Step Triage Checklist

Step 1: Is it down for everyone, or just you?

Before touching anything, rule out your own connection. A surprising share of "the site is down" reports turn out to be a stale DNS cache, a VPN, an office firewall or a hosting firewall that has banned one IP address.

• Load the site on your phone with Wi-Fi turned off. Mobile data uses a different network, a different DNS resolver and a different IP address.
• Check from outside your network entirely. The Is It Down? checker answers "down for everyone or just me?", and the multi-region website checker requests the URL from each SutramX probe region at once and shows the status code and timings from each.
• Turn off any VPN, proxy or browser extension that filters traffic, and try a private window.
• Flush your local DNS cache: ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, or resolvectl flush-caches on Linux with systemd-resolved.
• Check your hosts file (/etc/hosts, or C:\Windows\System32\drivers\etc\hosts) for an old entry pointing the domain at a previous server.

If the site works from everywhere except your network, the problem is local. Two causes worth knowing: firewalls such as fail2ban, CSF or a hosting provider's security layer can ban your IP after repeated failed logins, and some ISPs block domains at the DNS level, so the site is down for customers on one provider and fine for everyone else. If it fails from several networks and regions, it is a real outage. Keep going.

Step 2: Read the error

The browser's error message is the best clue you have. Each one points at a different layer:

• DNS_PROBE_FINISHED_NXDOMAIN or "server IP address could not be found"The domain does not resolve. DNS records, nameservers or domain registration. Go to steps 3 and 4.
• ERR_CONNECTION_REFUSEDThe domain resolves and the server is reachable, but nothing is listening on the port. The web server is stopped, or a firewall rejects the connection. Go to step 6.
• ERR_CONNECTION_TIMED_OUTPackets are going nowhere: the server is off, the IP address is wrong, or a firewall silently drops traffic. Check DNS points at the right IP (step 3), then the server and firewall (steps 6 and 8).
• NET::ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALIDThe TLS certificate is expired or does not cover this host name. Go to step 5.
• ERR_TOO_MANY_REDIRECTSA redirect loop, usually HTTP to HTTPS and back. A classic cause is a CDN connecting to the origin over HTTP (Cloudflare's Flexible SSL mode) while the origin redirects every HTTP request to HTTPS.
• 500, 502, 503 or 504The site is reachable and something behind it is failing. Go to step 6, and see the guides on 502, 503 and 504 errors.
• A Cloudflare 52x pageCloudflare is fine but cannot get a good answer from your origin: 521 refused, 522 timed out, 523 unreachable, 524 too slow, 525 and 526 TLS problems with the origin.
• The page loads but is blank or brokenThe server is up but the front end fails: a JavaScript error, assets returning 404 after a deploy, or an API the page depends on is down. Open the browser's developer tools console and network tab.

For any HTTP status code you do not recognise, the HTTP status code reference explains what it means and whether it signals an outage.

Step 3: Check DNS

DNS problems take whole sites down instantly and are easy to miss, because cached answers keep working for some people for a while. Query the records from more than one resolver:

• dig +short example.com A and dig +short www.example.com CNAME: do they return the address or target you expect?
• dig @1.1.1.1 example.com A and dig @8.8.8.8 example.com A: do public resolvers agree? Different answers usually mean a recent change still propagating, or nameservers that disagree with each other.
• dig +short example.com NS: are these still the nameservers where you manage the zone? A nameserver change at the registrar, often made while moving hosting, can silently replace your whole zone with an empty one.
• dig example.com +trace: follows delegation from the root down, and shows where the chain breaks.
• A SERVFAIL answer from public resolvers, while dig +cd (checking disabled) works, points at a broken DNSSEC setup, usually DS records left at the registrar after moving DNS providers.

The DNS checker compares a record across several public resolvers at once, which is the quickest way to see whether everyone gets the same answer.

Step 4: Check the domain has not expired

An expired domain is one of the most embarrassing outages, and one of the easiest to rule out. Run whois example.com (or look the domain up through your registrar or an RDAP lookup) and check the expiry date and status. A status of clientHold or serverHold means the registry has taken the domain out of DNS, which happens after expiry, for unpaid invoices, or when a registrar suspends a domain over missing contact verification. Renewing restores it, but resolvers may keep the failed answer cached for a while.

Step 5: Check the SSL certificate

If browsers show a certificate warning, inspect what the server is actually presenting: openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates. The notAfter line is the expiry date; the subject and the subject alternative names must cover the host name you visited.

Automatic renewal does not make this impossible. Certificates still expire because the web server was never reloaded after renewal, one server in a pool missed the new certificate, the validation method broke after a DNS change, or TLS is terminated at a load balancer or CDN with its own certificate. The guide why certificates still expire in production covers each case, and the SSL expiry checker shows the certificate a host is serving right now.

Step 6: Check the hosting server and application

If DNS and TLS are fine and the connection is refused, times out, or returns 5xx errors, the problem is on the server. In order:

• Check your hosting provider's status page and your account dashboard. Shared and managed hosts suspend accounts for unpaid invoices or resource abuse, and the result looks exactly like an outage.
• Can you reach the server at all? SSH in, or use the provider's console if SSH also fails.
• Is the web server running? systemctl status nginx (or apache2, httpd, caddy), and for the application systemctl status yourapp, docker ps -a or kubectl get pods.
• Is the disk full? df -h. A full disk stops databases, logs and uploads, and often takes the whole application with it.
• Did the kernel kill something for lack of memory? dmesg -T | grep -i "killed process".
• Is the database up? Many applications show a generic error when they cannot connect to it; WordPress shows "Error establishing a database connection".
• Read the logs: the web server error log (/var/log/nginx/error.log or /var/log/apache2/error.log) and the application log. The answer is usually in the last few minutes of one of them.

Step 7: Check the CDN and third parties

If your site runs behind a CDN, check the provider's status page, then test the origin directly to separate the two: curl -sv --resolve example.com:443:ORIGIN_IP https://example.com/ sends the request straight to your server with the right host name. If the origin works and the CDN does not, the problem is the CDN or the connection between them, such as an origin firewall that blocks the CDN's IP ranges.

Check the other services your site depends on, too: a payment provider, an authentication service, a headless CMS, a database-as-a-service. When one of them fails, your site can fail with it while your own server is perfectly healthy.

Step 8: What changed?

Most outages follow a change. Before deep debugging, list everything that changed in the last few hours: deploys, configuration edits, DNS changes, plugin or package updates, certificate renewals, firewall rules, a hosting plan change, a payment that failed. If a deploy lines up with the start of the outage, roll it back first and investigate afterwards. Restoring service is the priority; understanding can wait an hour.

Step 9: Check the firewall and WAF

Security layers can take a site down for some visitors and not others: a new geo-blocking rule, a rate limit set below real traffic, a bot rule that catches a legitimate integration, or an "under attack" mode that challenges every visitor. Check the WAF or CDN security events for blocked and challenged requests in the time window. If only your monitoring sees an outage, read why your monitor reports 403 while your site works.

Tell your users while you fix it

Once you know it is a real outage, post a short update before you have the cause. "We are investigating problems loading the site" within a few minutes prevents more support tickets than a detailed explanation an hour later. Say what is affected, what still works, and when the next update will be.

Post it on a status page that is hosted somewhere other than the site that is down, ideally on a different provider and DNS setup, so it stays up when your site does not. SutramX status pages are included on every plan and update automatically from your monitors; visitors can subscribe to email notifications when an incident starts and when it is resolved. The guide "Status pages: what to publish and how fast" covers wording and update cadence.

How to stop finding out from your customers

Every step above is a check you could have run automatically before anyone noticed. That is what website monitoring is: the same tests, on a schedule, from outside your infrastructure, with an alert when they fail.

• An HTTP monitor on the home page and on the pages that make money: login, checkout, the main API. Add a keyword check, so an error page served with status 200 still counts as down.
• Checks from more than one region, with failures confirmed across regions before anyone is paged, so you can tell a regional network problem from a global outage.
• Certificate and domain expiry reminders weeks in advance. SutramX HTTP monitors track both and can email you, and your connected chat channels, before either expires.
• A DNS monitor on the records your site depends on, so a changed or deleted record alerts you before caches expire and users notice.
• A status page tied to those monitors, so communication starts the moment an outage is confirmed.

Website down FAQ

How do I check if a website is down for everyone?

Load it from a different network, such as your phone on mobile data, and use an external checker that tests from several locations. If it fails everywhere, it is down; if it only fails for you, the cause is your network, DNS cache, VPN or a firewall that has blocked your IP.

Why is my website down for some people but not others?

Usually DNS (a recent change still propagating, or a resolver with a stale or broken answer), a problem in one region or at one CDN location, an ISP block, or a firewall or rate limit that blocks some visitors. Testing from several regions at once shows which.

What should I do first when my website goes down?

Confirm it is down from more than one network, read the exact error, and check what changed recently. If a deploy or config change lines up with the start, roll it back first. Then post a short status update so users know you are on it.

Next steps

• Is it down for everyone or just me?
• Website uptime checker from every probe region
• HTTP status code reference
• Uptime monitoring that tells you why a site is down