How to Check If a Website Is Down or Just Slow

When a website feels broken, people usually jump to one of two conclusions:

• the site is down
• my internet is broken

Both can be wrong.

A lot of “down” reports are really one of these:

• the site is up, but slow
• the edge is up, but the origin is struggling
• DNS changed and some users still have old answers
• a regional route is having a bad day

Start with the simplest question

Can you get any response at all?

If the answer is yes, the next question is not “is it down?”

It is:

what part of the path is slow or failing?

A practical workflow

1. Check the domain and response path

Use Website Performance.

That gives you quick outside-in answers like:

• did the page return a response?
• how long did the first byte take?
• how long did the document download take?
• were there redirects?
• is a CDN or edge layer involved?

If the page still returns a response, you are no longer in a pure outage check. You are in a performance or delivery-path investigation.

2. Check the DNS side

Use Domain Lookup if the problem started after a migration, nameserver change, certificate change, or mail cutover.

This helps you rule out:

• wrong nameservers
• bad A or AAAA records
• stale MX or TXT records
• obvious SSL mismatches

3. Compare what users are reporting

If some users can load the site and others cannot, the site may not be fully down.

That often points to:

• regional routing issues
• CDN edge variance
• resolver caching
• IPv6 problems

Signs a site is probably down

You are closer to a real outage when:

• the main document never returns successfully
• repeated checks fail the same way
• there is no useful HTTP response
• the domain resolution itself is broken

Even then, “down” can still mean different things. The origin may be down while the edge shows a branded error page. DNS may be broken while the host itself is still healthy.

Signs a site is probably slow, not down

You are closer to a performance issue when:

• the document returns, but first byte is high
• the page eventually loads
• the edge looks healthy but the origin is slow
• some pages are fine and one route is painful

That is why TTFB, HTML size, and cache behavior matter so much.

If you need the deeper explanation, read What Is TTFB and Why Is It High?.

Why CDN-backed sites confuse people

A CDN can make a website look partly alive even when the backend is having a rough time.

You might see:

• a fast edge error
• a cached page that still renders
• one region working while another struggles

That does not mean users are wrong. It means the path is layered.

Useful follow-up reads:

• What Is a CDN Edge Server?
• What Is an Origin Server and Why It Matters

Why “works for me” is not the same as healthy

This is especially true for global products.

A site can work from one city and fail from another because of:

• regional edge trouble
• BGP routing oddities
• broken IPv6
• cached DNS differences

That is why one browser session should never be treated as the whole truth.

The short version

If a site feels broken:

1. check whether the document responds at all
2. measure whether it is slow rather than dead
3. inspect DNS and hosting context
4. separate global issues from local ones

The real question is usually not “is the website down?”

It is:

which part of the path is failing, and for whom?