Why Is a Website Down? How Website Monitoring and Uptime Work

Is It Down for Everyone or Just Me?

When a website doesn't load, it could be a problem on your end (local network, ISP, DNS, browser) or on the server's end (actually down). The difference matters because the fix is completely different:

"Is it down for everyone or just me?"

Scenario A: Down for EVERYONE
  ┌──────────┐     ┌──────────┐     ┌──────────────────┐
  │  You     │────→│ Internet │────→│  Server (DOWN)   │
  └──────────┘     └──────────┘     │  ✗ 503 Error     │
  ┌──────────┐     ┌──────────┐     │  ✗ No Response   │
  │ User B   │────→│ Internet │────→│  ✗ Times Out     │
  └──────────┘     └──────────┘     └──────────────────┘
  → Problem is on the server side. Nothing you can do — wait.

Scenario B: Down for JUST YOU
  ┌──────────┐     ┌──────────┐     ┌──────────────────┐
  │  You     │──✗──│ ISP/DNS  │     │  Server (UP)     │
  └──────────┘     └──────────┘     │  ✓ 200 OK        │
  ┌──────────┐     ┌──────────┐     │  ✓ Responding    │
  │ User B   │────→│ Internet │────→│  ✓ Fast          │
  └──────────┘     └──────────┘     └──────────────────┘
  → Problem is on your side: DNS, ISP, firewall, cache, VPN, etc.

To determine which scenario:
  1. Check from a different network (mobile data vs Wi-Fi)
  2. Use an online "Is It Down" checker
  3. Ask someone else to try loading the site
  4. Check the site's status page (if they have one)

Why Websites Go Down

A website is a chain of systems — if any link breaks, the site goes down. Here's the full stack that must work for a web page to load:

What must work for a website to load:

You type: example.com

Step 1: DNS Resolution                    Failure = "DNS_PROBE_FINISHED"
  → Your DNS resolver → Root servers → TLD servers → Authoritative NS
  → Returns: 93.184.216.34

Step 2: TCP Connection                    Failure = "Connection timed out"
  → 3-way handshake with server on port 443
  → If server is overloaded or down, no connection

Step 3: TLS Handshake                     Failure = "SSL Error"
  → Certificate exchange, key negotiation
  → If cert expired or misconfigured → security warning

Step 4: HTTP Request                      Failure = 4xx/5xx status codes
  → GET / HTTP/1.1 → Host: example.com
  → Server processes request

Step 5: Application Processing            Failure = 500/502/503 errors
  → Web server (Nginx/Apache) → App server (Node/PHP/Python)
  → Database queries, API calls, rendering

Step 6: Response Delivery                 Failure = Partial load, timeouts
  → HTML, CSS, JS, images sent back
  → CDN serves static assets

Any of these steps can fail independently.

HTTP Status Codes — What the Numbers Mean

When a server responds, it sends a status code— a three-digit number that tells you exactly what happened. Understanding these codes is essential for diagnosing why a website isn't working:

Successful Responses (2xx)

Client Errors (4xx)

Server Errors (5xx) — "The Site Is Down"

How Website Monitoring Works

Website monitoring services continuously check whether a website is reachable and functioning correctly. Here's how they work under the hood:

How an uptime monitor works:

Monitoring Server(s) around the world:
  ┌──────────────────────────────────────────────────────┐
  │ Every 30-60 seconds:                                  │
  │                                                       │
  │ 1. Send HTTP(S) request to target URL                 │
  │    → GET https://example.com                          │
  │                                                       │
  │ 2. Check response:                                    │
  │    ✓ Status code 200? → Site is UP                    │
  │    ✗ Status code 5xx? → Site might be DOWN            │
  │    ✗ No response?     → Site is DOWN                  │
  │    ✗ Response > 10s?  → Site is SLOW (degraded)       │
  │                                                       │
  │ 3. Optionally check:                                  │
  │    • Response body contains expected text?             │
  │    • SSL certificate valid?                            │
  │    • Response time within threshold?                   │
  │                                                       │
  │ 4. If DOWN:                                           │
  │    → Confirm from 2-3 other locations (avoid false     │
  │      alarms from regional network issues)             │
  │    → Send alert (email, SMS, Slack, PagerDuty)        │
  │                                                       │
  │ 5. Record timestamp + status + response time          │
  │    → Build uptime history and SLA reports             │
  └──────────────────────────────────────────────────────┘

Multi-location monitoring:
  🇺🇸 New York     → checks example.com → UP (85ms)
  🇬🇧 London       → checks example.com → UP (120ms)
  🇯🇵 Tokyo        → checks example.com → DOWN (timeout)
  🇦🇺 Sydney       → checks example.com → DOWN (timeout)
  → Conclusion: Partial outage (Asia-Pacific routing issue)

Types of Monitoring Checks

Uptime Math — What "99.9%" Really Means

Uptimeis expressed as a percentage of time a service is available. Those decimal points matter more than you'd think — each additional "9" reduces allowed downtime by 10x:

Uptime calculation:

  Uptime % = (Total Time - Downtime) / Total Time × 100

  Example: Site had 2 hours downtime in a 30-day month
  → Total minutes = 30 × 24 × 60 = 43,200
  → Downtime minutes = 120
  → Uptime = (43,200 - 120) / 43,200 × 100 = 99.72%

SLA (Service Level Agreement):
  Cloud providers guarantee specific uptime levels:
  • AWS EC2:    99.99% (52 min downtime/year)
  • Google Cloud: 99.95% (4.38 hr downtime/year)
  • Azure VMs:  99.95%
  
  If they miss the SLA:
  → You get service credits (typically 10-30% of monthly bill)
  → Not actual money back — credits toward future usage

How to Check if a Website Is Down

There are several ways to determine whether a website is actually down:

Methods to check if a site is down:

1. Online "Is It Down" Checkers
   → External servers try to load the site for you
   → Confirms if it's down globally or just for you
   → Our Website Down Checker does exactly this

2. Browser Developer Tools
   → Open DevTools (F12) → Network tab
   → Look at the status code of the main request
   → 200 = OK, 5xx = server error, (failed) = can't connect

3. Command Line
   # Quick HTTP check
   $ curl -Is https://example.com | head -1
   HTTP/2 200   ← Site is UP

   $ curl -Is https://example.com | head -1
   HTTP/2 503   ← Service unavailable (DOWN)

   # Check if server is reachable
   $ ping example.com
   → Responses = server reachable (but web app might still be broken)
   → Timeout = server unreachable

4. Status Pages
   → Many services publish real-time status:
     status.aws.amazon.com
     www.githubstatus.com
     status.cloud.google.com

5. Social Media
   → Search Twitter/X for "[service] down"
   → DownDetector.com for crowd-sourced reports

Common Causes of Downtime

What to Do When a Site Won't Load (Visitor)

Before assuming a site is down, try these steps to rule out problems on your end:

Troubleshooting checklist (as a visitor):

Step 1: Hard refresh the page
  → Ctrl + Shift + R (Windows/Linux)
  → Cmd + Shift + R (Mac)
  → Clears cached version of the page

Step 2: Try a different browser or incognito mode
  → Rules out browser extensions, corrupted cache, cookies
  → If it works in incognito → clear your browser cache

Step 3: Check your internet connection
  → Can you load other websites? (google.com, etc.)
  → If nothing loads → your internet is down, not the site

Step 4: Try a different network
  → Switch from Wi-Fi to mobile data (or vice versa)
  → If it works → your ISP or local network is blocking it

Step 5: Flush your DNS cache
  → Windows: ipconfig /flushdns
  → macOS:   sudo dscacheutil -flushcache
  → Linux:   sudo systemd-resolve --flush-caches
  → Fixes stale DNS records pointing to old/wrong IP

Step 6: Try a different DNS server
  → Temporarily switch to 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare)
  → If it works → your DNS server had a problem

Step 7: Disable VPN / proxy
  → VPNs can route through blocked regions or overloaded nodes

Step 8: Use an online "Is It Down" checker
  → Confirms if the problem is on your end or theirs

Preventing Downtime (Site Owner)

If you run a website, here's how to minimize downtime:

Downtime Prevention Checklist:

Infrastructure:
  ✓ Use a CDN (Cloudflare, Fastly, CloudFront) for static assets
  ✓ Set up load balancing across multiple servers
  ✓ Use auto-scaling to handle traffic spikes
  ✓ Deploy across multiple availability zones/regions
  ✓ Keep database replicas for failover

Monitoring:
  ✓ Set up uptime monitoring (check every 1-5 minutes)
  ✓ Monitor from multiple geographic locations
  ✓ Alert via SMS/Slack/PagerDuty — not just email
  ✓ Monitor SSL certificate expiration (30-day warning)
  ✓ Track response times — slow is a warning sign

Deployment:
  ✓ Use blue-green or canary deployments
  ✓ Have instant rollback capability
  ✓ Run automated tests before deploying
  ✓ Deploy during low-traffic hours
  ✓ Never deploy on Fridays (infamous SRE rule)

DNS & Domain:
  ✓ Enable auto-renewal for domain registration
  ✓ Use multiple DNS providers for redundancy
  ✓ Set appropriate TTL values
  ✓ Monitor DNS resolution

SSL:
  ✓ Use auto-renewing certificates (Let's Encrypt + Certbot)
  ✓ Monitor certificate expiration
  ✓ Test certificate chain completeness

Backups:
  ✓ Automated daily backups (database + files)
  ✓ Test restoring from backups regularly
  ✓ Store backups in a different region

The Cost of Downtime

Downtime isn't just an inconvenience — it has real financial and reputational costs: