How to Check If a Website Is Down: A Developer Troubleshooting Guide

When a website will not load, the useful question is not only “is the website down?” The real goal is to identify where the request is failing: DNS, TLS, redirects, the web server, the application, a reverse proxy, or an upstream service.

A fast troubleshooting process checks the layers in a predictable order. That prevents you from changing DNS records when the real problem is a 500 error, or restarting an application when the domain is pointing to the wrong address.

1. Check the website status first

Start with the public URL that a real visitor uses.

Use Duck Cloud's Website Status Checker to inspect whether the URL is reachable, which HTTP status code it returns, how long the request takes, and whether redirects are involved.

Typical results include:

• 200 OK: the server returned a successful response;
• 301 or 308: the URL permanently redirects;
• 302 or 307: the URL temporarily redirects;
• 403 Forbidden: the server received the request but refused it;
• 404 Not Found: the requested route or resource is missing;
• 429 Too Many Requests: a rate limit is blocking traffic;
• 500 Internal Server Error: the application or server failed;
• 502 Bad Gateway: a proxy could not get a valid upstream response;
• 503 Service Unavailable: the service is temporarily unavailable;
• 504 Gateway Timeout: an upstream service took too long.

If you are unsure what a status code means, use the HTTP Status Code Lookup.

2. Inspect the redirect chain

A website can appear “down” because visitors are trapped in redirects.

For example:

http://example.com → https://example.com → https://www.example.com → https://example.com

That creates a loop.

Use the Redirect Checker to follow the chain. Look for unnecessary hops, loops, protocol changes, hostname changes, and redirects to invalid paths.

For production sites, prefer a short and intentional redirect path. Redirect old URLs directly to their final destination instead of creating several intermediate hops.

3. Check response headers

Headers often reveal problems that the page itself does not show.

Open the URL in the HTTP Header Checker and review:

• content-type;
• cache-control;
• location;
• content-length;
• server or proxy-related headers;
• security headers;
• CDN or cache indicators.

A common API failure is an endpoint that is expected to return JSON but actually returns an HTML login page or proxy error. Checking Content-Type quickly separates a transport problem from a parsing problem.

4. Verify DNS records

If the website cannot be reached at all, check DNS.

Use the DNS Lookup to inspect public A, AAAA, CNAME, TXT, MX, and NS records.

For a website outage, focus on:

• whether the expected A or AAAA record exists;
• whether a CNAME points to the correct hostname;
• whether the authoritative nameservers are correct;
• whether an old server IP is still being returned;
• whether both apex and www records are configured as intended.

If you recently moved hosting providers, an old cached answer may still appear for some users until the record's TTL expires.

5. Separate DNS, network, server, and application failures

A useful mental model is:

DNS failure: the domain cannot be resolved to the intended destination.

Connection failure: DNS works, but the destination does not accept the connection.

TLS failure: HTTPS negotiation fails because of a certificate, hostname, or protocol issue.

HTTP failure: the server responds, but with an error status or redirect problem.

Application failure: the web server works, but the framework, database, API, queue, or application code fails.

That classification determines what you should inspect next.

6. Check recent deployment changes

If the outage started immediately after a deployment, compare what changed:

• environment variables;
• database migrations;
• API keys;
• routes;
• build output;
• runtime versions;
• reverse-proxy configuration;
• Cloudflare or CDN rules;
• firewall rules;
• DNS records.

Roll back only when you understand the risk. A database migration, for example, may make a code rollback unsafe if the old application expects the old schema.

7. Test the origin separately when possible

When a CDN or reverse proxy sits in front of your application, determine whether the failure is at the edge or at the origin.

If the edge returns 502 or 504, review origin health, upstream ports, firewall rules, application logs, and timeouts.

If the origin is healthy but the public hostname is not, investigate proxy configuration, DNS, certificates, caching, or edge rules.

8. Watch for “works for me” failures

A website may work for you and fail for someone else because of:

• regional routing;
• DNS caching;
• IPv6;
• corporate or ISP filtering;
• browser cache;
• CDN edge differences;
• authentication state;
• cookies;
• geolocation rules.

Record the failing user's approximate region, timestamp, URL, error message, and status code. That evidence is much more useful than “the site is broken.”

Website-down checklist

1. Check the public URL with the Website Status Checker.
2. Look up unfamiliar codes with the HTTP Status Code Lookup.
3. Trace redirects with the Redirect Checker.
4. Inspect response headers with the HTTP Header Checker.
5. Verify DNS with the DNS Lookup.
6. Review deployments, logs, environment variables, and upstream services.
7. Compare edge behavior with the origin when a CDN or proxy is involved.
8. Record the exact error before changing configuration.

A website outage becomes much easier to solve when you stop treating it as one problem and instead identify the exact layer that failed.