When a website appears down, the fastest path to a fix is to identify where the request stops. “The site is down” can mean a domain no longer resolves, a server cannot be reached, a TLS certificate has failed, or an application is returning an error.

Work from the outside in. Each successful step narrows the next one.

1. Confirm the scope of the problem

Try the exact URL in a private browser window and from a different network when possible. Check both the root domain and www, since they can have different DNS records and server configuration. Ask whether the issue affects every page, only logged-in users, or a specific region.

Capture the actual symptom: a browser error, timeout, certificate warning, or HTTP status code. That detail is far more useful than a generic report that the page “doesn’t work.”

2. Check DNS resolution

Run a DNS lookup for the hostname that fails. Verify that the A, AAAA, or CNAME response matches the intended host or CDN. If you recently changed nameservers or migrated hosting, also confirm that the registrar points to the DNS provider you are editing.

Watch for these common mistakes:

• The root domain is correct but www still points to an old host
• An AAAA record sends IPv6 visitors to a server that is not configured
• A CNAME target is misspelled or no longer exists
• Records were changed, but resolvers still have the old answer cached until TTL expiry

If DNS answers are correct in one place but not another just after a change, record the TTL and when the change was made before making more edits.

3. Test the network path

Use a ping test as one data point for reachability. A failed ping does not prove a site is offline—many firewalls deliberately ignore ICMP—but packet loss or unusually high latency can help explain a timeout.

For a more detailed view, run a traceroute. It can reveal where packets begin to slow down or stop. Treat individual nonresponsive hops carefully: routers often deprioritize traceroute replies while still forwarding normal web traffic.

4. Check the web server and ports

If the hostname resolves, confirm that the web server is listening on the expected port. HTTPS normally uses 443 and HTTP normally uses 80. A port check can show whether the public service is reachable, while server logs and firewall rules explain why it may not be.

If the port is open but the browser still fails, inspect the HTTP response. A 502 or 504 commonly points to a proxy or upstream application issue; a 500 means the application encountered an error; a 403 may be a firewall, permissions, or security rule.

5. Verify TLS and redirects

Certificate warnings can make a working server look unavailable. Check that the certificate covers the requested hostname, has not expired, and that the complete certificate chain is configured. Then test the redirect path from http to https and from www to the canonical host. Redirect loops and long chains create their own failure mode.

6. Inspect the application and recent changes

Once DNS, connectivity, and TLS are sound, focus on the application. Look at error logs, deployment activity, configuration changes, background jobs, database availability, and third-party integrations. Recent changes are especially valuable clues, but verify them with timestamps before rolling anything back.

Keep a short incident record

For a recurring issue, write down the affected URL, time zone, error message, test location, and the result of each check. This makes handoffs faster and lets you spot patterns such as an issue tied to a particular release or region.

This sequence keeps an outage manageable: resolve the name, reach the server, establish HTTPS, inspect the response, then investigate the application. It replaces random changes with evidence at every layer.