How to Check if a Website Is Down (And What to Do About It)

You click a link, and nothing happens. The page spins. Eventually your browser gives up and shows an error. Is the website actually down, or is something wrong on your end? The answer matters -- if you are a visitor waiting for access, it saves you from pointless troubleshooting. If you are the site owner, every minute of unexplained downtime costs money and trust.

This guide walks through how to systematically diagnose whether a website is truly down, what the error messages mean, and what concrete steps to take depending on what you find.

Is It Down for Everyone, or Just You?

The first question to answer is scope. A site that is unreachable from your machine but accessible from the rest of the internet is a fundamentally different problem than a global outage.

Quick Local Checks

Before assuming a site is down, rule out your own connection:

1. Try a different website. If google.com loads fine, your internet connection is probably working.
2. Switch networks. Turn off Wi-Fi and try on mobile data, or vice versa. If the site loads on one network but not another, the problem is between your network and the server, not the server itself.
3. Clear your DNS cache. Your operating system caches DNS lookups. If a site recently changed servers, your machine might still be pointing at the old address.

   # Windows
   ipconfig /flushdns
   
   # macOS
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   
   # Linux
   sudo systemd-resolve --flush-caches

4. Try a different browser or incognito mode. Browser extensions, corrupted caches, or stale cookies can sometimes prevent pages from loading.

Check from an External Source

If the site still will not load after ruling out local issues, verify from an independent vantage point. Services like HTTP Tiger check a URL from external infrastructure, so the result is not influenced by your local network, ISP, or DNS resolver.

What HTTP Status Codes Actually Mean

When you request a web page, the server responds with a three-digit status code. Understanding these codes tells you exactly where the problem lives.

The Codes You Will See During Downtime

5xx -- Server Errors

These mean the server received your request but failed to fulfill it. The problem is on the server side.

• 500 Internal Server Error -- A generic catch-all. The server encountered something unexpected. Common causes: a crashed application, a syntax error in server configuration, or a failed database query.
• 502 Bad Gateway -- A reverse proxy or load balancer tried to forward your request to a backend server but got an invalid response. This often means the application server behind Nginx or a CDN has crashed or is not running.
• 503 Service Unavailable -- The server is intentionally refusing requests, usually because it is overloaded or undergoing maintenance. Unlike 500, this is often temporary and deliberate.
• 504 Gateway Timeout -- The proxy or load balancer waited for a response from the backend, but it never came. The backend server might be alive but too slow or stuck processing a heavy request.

4xx -- Client Errors

These mean the server is working, but it is refusing your specific request.

• 403 Forbidden -- The server understood your request but refuses to authorize it. You might be blocked by IP, by geographic region, or by a Web Application Firewall (WAF) that flagged your request.
• 404 Not Found -- The specific page does not exist. The server itself is fine -- you just have a bad URL.
• 429 Too Many Requests -- You (or your IP) sent too many requests in a short period. Rate limiting kicked in. Wait and retry.

No Response At All

If you get no HTTP status code -- just a browser timeout or "connection refused" error -- that means the server is either completely offline, unreachable over the network, or not listening on port 80/443. This is the most severe type of outage.

DNS Issues vs Server Issues: How to Tell the Difference

When a website will not load, the problem falls into one of two broad categories: either your browser cannot find the server's address (DNS), or it found the address but the server is not responding properly (server).

Diagnosing DNS Problems

DNS (Domain Name System) translates domain names like example.com into IP addresses like 93.184.216.34. If this lookup fails, your browser has nowhere to send the request.

Test DNS resolution directly:

# Check if the domain resolves to an IP
nslookup example.com

# More detailed lookup
dig example.com

# Use a specific DNS server (Google's)
nslookup example.com 8.8.8.8

If the domain does not resolve at all: The DNS records may have been deleted, the domain may have expired, or the nameservers may be misconfigured. If it resolves using Google's DNS (8.8.8.8) but not your default DNS, the problem is with your ISP's DNS servers.

If the domain resolves to the wrong IP: DNS records may have been recently changed, and propagation is still in progress. DNS changes can take up to 48 hours to propagate globally, though most complete within a few hours.

Diagnosing Server Problems

If DNS resolves correctly but the site still will not load, the problem is at the server level. Test the connection directly:

# Check if the server is accepting connections on port 443 (HTTPS)
curl -I https://example.com

# Test with a timeout to avoid waiting forever
curl -I --max-time 10 https://example.com

# Check raw TCP connectivity
telnet example.com 443

If curl returns a status code (even 500), the server is alive -- it is just unhappy. If curl times out or shows "connection refused," the server process is either not running or a firewall is blocking the connection.

When the CDN Is the Problem

Content Delivery Networks (CDNs) like Cloudflare, CloudFront, and Fastly sit between users and origin servers. They cache content at edge locations around the world to reduce latency. But they also introduce another layer where things can go wrong.

CDN-Specific Failure Modes

• Edge node failure: The CDN node nearest to you is down, but the site works from other regions. This is why testing from multiple locations is critical.
• Origin fetch failure: The CDN cache has expired and it tries to refresh from your origin server, but the origin is down. You see a CDN error page (Cloudflare's "Error 522," CloudFront's "502 ERROR") instead of your actual site.
• SSL mismatch: The CDN's SSL certificate does not match the domain, or the connection between CDN and origin uses incompatible SSL settings.
• Cache poisoning: A bad response got cached at the CDN layer. The origin is healthy, but the CDN keeps serving a stale error. Purging the CDN cache fixes this.

Troubleshooting Flowchart

When a website is not loading, work through this sequence to isolate the problem:

Checking from Multiple Locations

A website can be down in one region and perfectly healthy in another. This happens more often than people realize, and it makes single-location checks unreliable for diagnosing outages.

Why Location Matters

• Regional DNS failures: DNS is a distributed system. A misconfigured DNS record might have propagated to some resolvers but not others.
• CDN edge failures: If the Paris CDN node is down but the Frankfurt node is healthy, European users in France see downtime while users in Germany do not.
• Routing issues: Internet traffic does not travel in a straight line. A fiber cut in one region can make a site unreachable from certain ISPs while others route around the damage.
• Geographic blocking: Some sites restrict access by country, either deliberately (licensing restrictions) or accidentally (overly aggressive WAF rules).

Tools that check from multiple global locations simultaneously give you a map of where the problem actually exists. HTTP Tiger's monitoring checks your site from distributed infrastructure, so a regional outage gets flagged even if the site is healthy from other vantage points.

Using Command-Line Tools for Multi-Location Testing

If you have access to servers in different regions (cloud instances, VPNs, or SSH access to remote machines), you can run your own distributed checks:

# From each remote server, test the target
curl -o /dev/null -s -w "HTTP Code: %{http_code}\nTime: %{time_total}s\nIP: %{remote_ip}\n" https://example.com

# Check the route your traffic takes
traceroute example.com

# Check which DNS server you are hitting and what it returns
dig example.com +short

Setting Up Monitoring So You Know First

The worst way to find out your site is down is from a customer email. Proactive monitoring means you get an alert within minutes of an outage -- often before any user even notices.

What Good Monitoring Looks Like

Effective uptime monitoring is not just "ping the homepage every 5 minutes." A robust setup includes:

1. Multiple endpoints. Monitor your homepage, your API, your login page, and any critical paths. A working homepage does not mean your checkout flow is functional.
2. Content validation. Do not just check for a 200 status code. Verify that the response body contains expected content. A 200 response that serves an empty page or an error message in HTML is still a broken site.
3. Reasonable intervals. For most sites, checking every 1-5 minutes strikes the right balance between catching outages quickly and not generating excessive traffic.
4. Multi-location checks. A check from a single location might miss regional outages. Checking from at least 3 geographically distributed points gives a more accurate picture.
5. Escalation tiers. First alert goes to the on-call engineer via push notification. If not acknowledged in 10 minutes, escalate to SMS. If unacknowledged in 30 minutes, escalate to the team lead.

Alert Fatigue Is Real

A monitoring system that fires alerts for every brief blip trains people to ignore alerts. Configure your monitors to require consecutive failures before triggering -- typically 2-3 failed checks in a row. A single failed check followed by a successful one is usually transient network noise, not a real outage.

What to Do When Your Own Site Goes Down

Knowing a site is down is step one. Fixing it is step two. Here is a practical response framework for site owners.

Immediate Response (First 5 Minutes)

1. Verify the outage. Confirm from an external tool that the site is genuinely down, not just slow or unreachable from your location.
2. Check your hosting provider's status page. AWS, GCP, Azure, DigitalOcean, Vercel -- all have status pages. If your provider is having an incident, there may be nothing you can do except wait.
3. Check recent deployments. The most common cause of sudden downtime is a bad deployment. If someone pushed code in the last hour, roll it back first, investigate second.

Investigation (5-30 Minutes)

1. Read the server logs. Application logs, web server error logs, and system logs almost always contain the answer. Look for stack traces, out-of-memory errors, or disk-full warnings.
2. Check system resources. Is the server out of memory? Is the disk full? Is CPU at 100%? These are the most common infrastructure causes of crashes.
3. Check dependent services. Is the database reachable? Are third-party APIs responding? Is the cache (Redis, Memcached) available? A site can crash because a single dependency timed out.

Communication

If the outage lasts more than a few minutes, communicate proactively. Update your status page. Post to social media. Send an email to affected customers if appropriate. Users are far more forgiving of downtime when they know you are aware and working on it than when they are left wondering in silence.

Post-Incident

After recovery, write a brief incident report: what happened, when it started, when it was resolved, what the root cause was, and what you are doing to prevent it from happening again. This discipline prevents the same class of failure from recurring.