Skip to content

Guide

How to Know If a Website Is Down

Your site isn't loading. Or maybe it is loading, but something looks wrong. How do you tell the difference between "the server is down," "it's just your connection," and "the server says it's fine but the page is broken"? This guide covers every method — from quick browser checks to the deeper failures that most monitoring tools miss.

  • 5 methods to check if a site is really down
  • The "up but broken" problem explained
  • What to do when your site is down
Check your site now Get continuous monitoring

Start here

5 ways to check if a website is down

1. Try a different device or network

Before assuming the site is down for everyone, rule out local issues. Try loading the site on your phone (using mobile data, not Wi-Fi) or ask someone in a different location. If it works for them, the problem is likely your DNS cache, ISP, or local network.

2. Check the HTTP status code

Open your browser's developer tools (F12 → Network tab) and reload the page. Look at the status code for the main document request:

  • 200 — The server responded successfully (but the page might still be broken — more on this below)
  • 301/302 — Redirect. Follow the chain. If it loops, that's your problem.
  • 403 — Forbidden. Server is up but blocking access.
  • 404 — Page not found. Server is up, but this specific page doesn't exist.
  • 500 — Internal server error. The server is up but crashing.
  • 502/503 — Bad gateway or service unavailable. Usually a backend or load balancer issue.
  • No response / ERR_CONNECTION_REFUSED — Server is actually down or unreachable.

3. Check DNS resolution

DNS translates your domain name to an IP address. If DNS fails, the browser can't even find your server. You can check DNS from your terminal:

nslookup yoursite.com or dig yoursite.com

If this returns no results or a wrong IP, the problem is DNS — check your domain registrar and DNS provider.

4. Check SSL/TLS certificate

An expired or misconfigured SSL certificate will make browsers show a scary warning page. Click the padlock icon in your browser's address bar to check certificate validity. Common issues: expired cert, cert for wrong domain, or incomplete certificate chain.

5. Use an external checker

Tools like our free website checker test your site from an external server, removing your local network from the equation. If the site is up from an external check but down for you, the issue is between you and the server (DNS, ISP, CDN edge node).

11

Detection rules

Free

Website checker

Instant

Results

The hidden failure

When your site is "up" but broken

Here's what most "is it down" guides won't tell you: the most common user-facing failures happen when your server is responding normally.

Your server returns 200 OK. Your uptime monitor says "all good." But your users see a broken page. This is the "up but broken" problem, and it's responsible for more lost revenue than actual downtime.

How does a site become "up but broken"?

Broken JavaScript after a deploy. You ship a new version. The HTML references app.a3f2c1.js. But the CDN purged the old file and hasn't cached the new one yet — or the filename hash changed. Result: your app's entire frontend doesn't load. Server says 200. Users see a blank page or non-functional buttons.

Missing or mismatched stylesheets. A CSS file returns a 200 but with a text/plain MIME type instead of text/css. Browsers silently block it. Your page renders as raw, unstyled HTML. Speed tests might even report faster load times.

Third-party script failures. Your payment processor, analytics, or authentication provider's JavaScript fails to load from their CDN. Your page loads fine — but the checkout form, login button, or tracking pixel doesn't work.

Stale CDN cache. Your CDN edge node in Europe serves an old, broken version of a script. Users in the US see a perfect site. European users see a broken one. Your server is healthy. The CDN isn't.

How to detect "up but broken" failures

Traditional uptime monitoring (pinging the server) can't detect these issues by design — the server is up. You need website monitoring that goes deeper:

  • Fetches the actual page (not just pings the server)
  • Parses the HTML and finds every linked asset
  • Validates each JS, CSS, image, and font file individually
  • Checks MIME types, status codes, and content integrity
  • Fingerprints the page content to detect unexpected changes

This is exactly what Sitewatch does. It's the monitoring layer between "server responds" and "page works for users."

Action plan

What to do when your site is down

01

Confirm it's not just you

Check from another device/network or use an external checker. If it's only down for you, the issue is DNS, your ISP, or a CDN edge node.

02

Check your hosting

Log into your hosting provider's status page. Check server metrics — CPU, memory, disk space. Look at error logs for 500-series errors or process crashes.

03

Check recent deploys

If the timing correlates with a deploy, that's likely the cause. Check if asset filenames changed, if build artifacts are missing, or if the deploy partially failed.

04

Set up real monitoring

Reactive checking (visiting the site after users complain) is too slow. Set up website monitoring that validates your site automatically and alerts you when things break.

Start monitoring today

Free plan. No credit card.

Get started free

Common questions

Stop guessing. Start monitoring.

Free plan available. Know when your site breaks before your users tell you.

Start free monitoring