Check a site
Check a website Service status Outages Blog
All tools
Check a websiteBrowse all tools
Five stacked layers labelled DNS, connect, TLS, HTTP and content, with one layer flagged red

Guides

Is your website down? A layer-by-layer troubleshooting guide for site owners

Posted Jimel S.4 min read

When your site stops loading, work through it in the same order a browser does: DNS, connection, certificate, HTTP response and content. This guide shows how to find the broken layer in minutes, what each error code means and what to check on the server.

Illustration: UtiBox

Your phone buzzes: “the site’s down”. The fastest way to fix it is to stop guessing and check the layers in the order a browser goes through them. The first layer that fails is almost always where the problem is.

Step 0: Is it down for everyone?

Before you touch anything, check from somewhere other than your own network. The Website Down Checker opens your site from our server and shows each step of the request. If it loads fine from there, the problem is more likely your connection, your network or your device. Run the Connection Test to check your own line.

If our server can’t reach it either, carry on through the layers below.

Layer 1: DNS (does the name still point to your server?)

Every visit starts by turning your domain name into an IP address. Problems here look like “server not found” or DNS_PROBE_FINISHED_NXDOMAIN.

  • Use DNS Lookup to see the A, AAAA and CNAME records. Do they point at your current server or load balancer?
  • Changed DNS recently? Use the DNS Propagation Checker to see whether six large public resolvers have the new answer yet.
  • Check the domain hasn’t expired with WHOIS Lookup. An expired domain is a surprisingly common cause of “everything is down”.

Layer 2: Connection (is the server answering at all?)

If DNS is right but nothing connects, the server is off, overloaded, or a firewall is blocking it.

  • The Ping Test measures how long a TCP connection to your web port takes, five times in a row. Failures or wildly varying times point at the server or the network in front of it.
  • Many servers block ICMP, so a classic ping failing doesn’t prove much on its own. A failed connection to port 443 does.

Layer 3: TLS (is the certificate valid?)

A broken certificate shows visitors a full-page warning such as NET::ERR_CERT_DATE_INVALID instead of your site. Run the SSL Certificate Checker and look at the days left, the names covered and the chain. Our certificate guide covers the five usual causes.

Layer 4: HTTP (what is the server saying?)

If the connection and certificate are fine, the HTTP Status Checker shows the exact status code and headers your site returns. The code tells you where to look:

CodeWhat it usually meansWhere to look
500The application crashedApplication and PHP or framework error logs
502The web server couldn’t get an answer from the app behind itIs PHP-FPM, Node or your app server running?
503Overloaded, or in maintenance modeResource usage, maintenance flags, rate limits
504The app took too long to answerSlow database queries, external APIs, timeouts
403Access refusedFile permissions, .htaccess, firewall or WAF rules
404The page isn’t thereDeploy path, rewrites, recently moved pages

Site stuck in a loop, or ending up somewhere odd? The Redirect Checker lists every hop. Redirect loops between http and https, or between www and the bare domain, are common after changing CDN or SSL settings.

Layer 5: Content (it loads, but something is wrong)

Sometimes the server says 200 OK but the page is blank, half-styled or very slow. The Response Time Test shows how long the page takes, and the Website Health Report checks every layer at once, including the page title and six security headers, which makes it a quick before-and-after comparison.

On the server: the usual suspects

Once you know which layer failed, these commands find most causes on a Linux server:

# Is the web server running?
sudo systemctl status nginx        # or apache2 / httpd
sudo systemctl status php8.4-fpm   # name varies with your PHP version

# What do the logs say?
sudo tail -n 50 /var/log/nginx/error.log
sudo journalctl -u php8.4-fpm --since "30 min ago"

# Out of disk or memory?
df -h
free -m

# Is anything listening on 80 and 443?
sudo ss -tlnp | grep -E ':80|:443'

A full disk quietly breaks databases, sessions and logs, and it’s behind a surprising number of 500 and 502 errors. Clearing old logs and backups often brings a site straight back.

While you fix it

  • Tell people. A short post on your status page or social accounts saves you dozens of messages.
  • Change one thing at a time, and write down what you changed, so you can undo it.
  • Afterwards, note what failed, how you found it and what would have warned you sooner. That’s the start of proper monitoring.

Checking a big service instead?

If it’s not your site but a service you rely on (GitHub, Cloudflare, Steam, ChatGPT), check its UtiBox status page. It combines our own measurements, checks from other regions, what other visitors are reporting and the provider’s official status.

Check a website now

Related

More from Guides

Most read

Latest

Most read

  1. 01November Patch Tuesday lands on the 10th: what October’s record release tells us19
  2. 02Introducing UtiBox: the Web’s Utility Box2
  3. 03Ivanti Connect Secure zero-days gave attackers root on VPN gateways1
  4. 04“Black October”: attackers raid secrets at cloud and AI developer platforms1

Embed this post

Paste this code into your page. It shows the post as a card that links back here. In WordPress you can also paste the post’s address on a line of its own.

Cookies on UtiBox

UtiBox is free because of ads. Google and its partners use cookies to show, limit and measure ads, Google Analytics, Ahrefs Web Analytics and Microsoft Clarity show us how the site is used, and we use a few essential cookies to run the site.