Is My Website Down? How to Check From Outside in 60 Seconds

You loaded your website. It did not load. Or it loaded with the wrong content. Or your customer says it is broken but it works fine for you. Before you wake up an engineer or refresh-rage at the page, you need 60 seconds of actual evidence.

This is the no-nonsense version of "is my website down?" Five external checks you can run from the device in front of you, in order, that will tell you whether the site is really down, down only in some regions, down only for some users, or only down for you.

If you already know it is really down and want to fix it, jump to Website Down — How to Check and Fix. This guide is the confirm it is actually down step.

The 60-Second Outside Check (TL;DR)

In order, fastest first:

Open the site on mobile data (Wi-Fi off) - rules out your home/office network.
Try a third-party "is it up?" checker from a different network - rules out your ISP.
dig or nslookup the domain - rules out DNS.
curl -I the URL with full headers - rules out CDN or 200-with-wrong-content lies.
Check your monitoring dashboard or status page for the same URL from other regions.

If steps 1-5 all say "up" but the customer still cannot reach you, it is almost certainly a regional or routing issue, not a global outage. Keep reading.

Step 1: Mobile Data Check (5 seconds)

Most "the site is down" reports are your network, not the site.

Disconnect Wi-Fi on your phone.
Open the site on cellular data.
If it loads - your local network or DNS resolver is the problem, not the site.

This is the single highest-value check because it eliminates the most common false positive: a router, captive portal, VPN, corporate firewall, or a stale DNS entry on your laptop.

Step 2: Third-Party Checkers (15 seconds)

Use at least two external "is it up?" tools so a single tool's outage does not fool you:

A "down for everyone or just me?" style checker
A multi-region uptime checker
A WHOIS / status lookup for the domain

What you are looking for:

"Down everywhere" → real outage.
"Up from some checkers, down from others" → regional or routing issue.
"Up everywhere" → almost certainly local to you.

Webalert can do this directly: see How Webalert Helps at the end.

Step 3: DNS Lookup (10 seconds)

If DNS is broken, nothing else matters. The browser cannot find the server's IP.

On macOS or Linux:

dig example.com +short
dig example.com AAAA +short
dig example.com NS +short

On Windows:

nslookup example.com
nslookup -type=NS example.com

What to check:

No A or AAAA record returned → DNS is broken. The domain might have expired, the DNS host might be down, or a recent change has not propagated.
Different IP than expected → someone changed DNS (intentionally or not).
NS records pointing at the wrong host → DNS host change in progress.
TTL much higher than usual → an old cached record may be stuck.

For domain-level issues, see Domain Expiry & WHOIS Monitoring and DNS Propagation Monitoring.

You can also force a non-local DNS resolver to rule out a poisoned local resolver:

dig @1.1.1.1 example.com +short
dig @8.8.8.8 example.com +short

If 1.1.1.1 and 8.8.8.8 disagree, you are mid-propagation or there is split-horizon DNS in play.

Step 4: curl With Full Headers (10 seconds)

Status codes lie. So do CDNs. curl -I shows the truth:

curl -sSI -L https://example.com | sed -n '1,20p'

What the output tells you:

HTTP/2 200 with sensible content-type, cache-control, set-cookie → server is responding.
HTTP/2 301 or 302 followed by another response → redirect chain. Make sure the chain ends at the real page. See Redirect Chain Monitoring.
HTTP/2 5xx → server is up, application is broken. See 5xx Server Error Rate Monitoring.
curl: (6) Could not resolve host → DNS again. Recheck step 3.
curl: (7) Failed to connect → server refusing connections (firewall, security group, instance down).
curl: (28) Operation timed out → server reachable but not responding within the timeout. Routing or capacity problem.
SSL certificate problem → TLS broken. See TLS Configuration Monitoring.

To see the body and confirm the page is actually correct (not the dreaded "200 OK with login page" outage), drop the -I:

curl -sSL https://example.com | head -40

A 200 status with a maintenance page or a login page is still an outage from the user's perspective. See Response Body Validation Monitoring.

Step 5: Multi-Region Check (15 seconds)

The four checks above all came from one device on one network. To rule out regional issues, you need eyes in multiple regions:

A monitoring dashboard with checks in US, EU, and APAC.
A traceroute from a public looking-glass server in another region.
Your own status page if checks feed it.

The patterns you will see:

Pattern	Likely cause
All regions down at once	Origin server / app / database outage
One region down, others up	CDN edge, ISP peering issue, or regional cloud provider incident
Mobile up, fiber down (same area)	Local ISP routing problem
Down via IPv4, up via IPv6 (or vice versa)	Routing or firewall rule difference
Up from monitors, down from a specific country	Geo-block, BGP route leak, or government-level filtering

If you do not have multi-region monitoring yet, see Multi-Region Monitoring for why you need it before the next incident.

Layer-By-Layer Diagnosis Tree

If the basic checks were inconclusive, walk the stack from outside in:

DNS layer

dig example.com +short
dig www.example.com +short
dig example.com NS +short

Broken? Fix DNS first. Nothing else matters. See also Domain Expiry Monitoring.

Network layer

ping -c 5 example.com
mtr -c 20 example.com   # or traceroute

ping confirms basic ICMP reachability (some hosts block ICMP - do not panic if pings drop but HTTP works). mtr shows where packets are being dropped. See Ping Monitoring.

Transport layer

nc -zv example.com 80
nc -zv example.com 443

If TCP connect fails, the server, the firewall, or the load balancer is refusing connections. See Port Monitoring.

TLS layer

openssl s_client -connect example.com:443 -servername example.com </dev/null \
  | openssl x509 -noout -dates -subject -issuer

Expired cert, wrong SAN, missing chain - any of these will look like "site down" in a browser. See TLS Configuration Monitoring.

Application layer

curl -sSI -L https://example.com
curl -sSL https://example.com | head -50

Status codes and body content. Combine with HTTP Status Codes Explained.

Content layer

curl -sSL https://example.com | grep -E 'Sign in|Maintenance|Application Error'

The site can return 200 and still be "down" if it is serving a login page, an error template, or last week's build. See Response Body Validation Monitoring.

"It Works For Me, But Not For The Customer"

When the site loads for you and a few teammates but customers complain:

Ask the customer for their country, ISP, and rough city.
Ask for the exact URL - sometimes only one route or product page is broken.
Ask for a screenshot with the URL bar and any error visible.
Run a check from the closest monitoring region.
Test from a public mobile network or a VPN exit in that country.

Most "it works for me" stories collapse into one of:

A CDN edge in that region is unhealthy.
Their ISP has a routing problem to your origin.
A WAF or geo-block rule is rejecting their IP range.
A specific URL or product is broken; your homepage is fine.
Their device or browser cached a broken version of the site.

Ask the customer to test the same URL on mobile data with cache disabled. If that works, the issue is local to them.

"My Monitor Says Up But The Site Is Down"

A common, embarrassing scenario. Reasons:

The monitor checks only the homepage, but the broken page is /checkout.
The monitor accepts any 2xx status, but the page is serving a maintenance template at 200.
The monitor only checks from one region.
The monitor only checks every 5 minutes - it missed a 90-second blip.
The monitor checks an internal health endpoint that does not actually exercise the broken dependency.

Fix the monitor:

Monitor the URLs that matter, not the easiest URL to set up.
Add content assertions so "200 with wrong content" fails the check.
Run from multiple regions.
Use 1-minute intervals on critical paths. See 1-minute vs 5-minute monitoring.
Make sure your health endpoint actually exercises the dependencies. See Health Check Endpoint Design.

"My Monitor Says Down But The Site Is Up"

Less common but very disruptive (especially at 3am):

Monitor's outbound IP is geoblocked by your WAF.
Monitor uses a stricter TLS version than browsers.
Monitor's region is having ISP issues, not your site.
Monitor's user-agent is rate-limited.
A scheduled maintenance window is not configured in the monitor.

When a single monitoring source disagrees with reality, cross-check from another tool before opening an incident.

Status Page Sanity Check

If you run a public status page, your "is the site down?" answer should also be on the status page:

Does the status page show the same incident your monitor saw?
Is the status page itself up? (It cannot share infrastructure with the thing it reports on.)
Are your customers being notified?

For the broader process, see Incident Communication and Incident Runbook Template.

After You Confirm It Is Really Down

Now you have evidence. Open an incident, page the right people, and follow your runbook. If you do not have one yet, see Incident Runbook Template and Reduce MTTR.

When the incident is over:

Post a clear status update.
Match what you said publicly to what your monitor recorded.
Write a post-mortem - see Incident Post-Mortem Template.
Improve the monitoring gap that let it surprise you.

"Is My Website Down?" Checklist

Tested from mobile data (off home/office network)
At least two third-party checkers consulted
DNS resolves the expected IP from at least two public resolvers
curl -I returns the expected status code and headers
Body content matches a healthy page (not a login or maintenance template)
At least one other region tested
TLS certificate valid and chain complete
Monitoring dashboard matches your manual observation
Status page matches monitoring
Customer's exact URL, country, and ISP captured if relevant
Decision documented: real outage / regional / local / false alarm

How Webalert Helps

Webalert is the always-on version of the manual checklist above:

External multi-region checks - US, EU, APAC, more - so you can see exactly which regions can or cannot reach the site.
DNS, TLS, and port checks - DNS resolution, certificate validity, TCP reachability are monitored independently from HTTP, so you can see which layer failed.
Content validation - Set required and forbidden text so a 200 with a maintenance page is still recorded as down. See Response Body Validation Monitoring.
1-minute checks - Short blips do not slip through. See 1-minute vs 5-minute monitoring.
Status page - Customers see the same data your monitor sees, in real time.
Alerts to the right channel - Slack, Discord, Microsoft Teams, SMS, email. See Slack Alerts, Discord Alerts, SMS Alerts.
Public report URL - When a customer asks "is your site down?", point them at the report.

Example Webalert check that catches everything in this guide:

URL: https://example.com/
Method: GET
Regions: US-East, EU-West, AP-Southeast
Frequency: every 60 seconds
Pass condition: HTTP 200, body contains Get started, body does not contain Maintenance or Sign in, response time under 2000ms
TLS expiry warning: 14 days
DNS warning if A record changes unexpectedly
Alert routing: Slack on first failure, SMS if down for 3 minutes in 2 regions

Summary

Before you panic about an outage, take 60 seconds to confirm it from outside. Mobile data, third-party checker, DNS lookup, curl -I, multi-region check. That sequence will tell you whether the site is really down, regionally down, or only down for you.

Once you have evidence, fix the actual layer that broke - DNS, network, TLS, app, content. Then audit your monitoring so the next time, the answer to "is my website down?" comes from a dashboard, not from a customer support ticket.

Stop guessing whether your site is really down

Start monitoring with Webalert ->

See features and pricing. No credit card required.