Spot Downtime

Website down? A 10-minute checklist to find the cause

A calm, step-by-step way to find out why a site is down: is it really down, DNS, the certificate, the server, or the app. Each step takes a minute and says what to do next.

· 5 min read · By the Spot Downtime team

Your site is down, or someone says it is. The temptation is to restart everything and hope. Don't: a restart can wipe the evidence and may not fix the cause. Work from the outside in instead. Each step below takes about a minute, rules out a whole class of problems, and tells you where to look next.

1. Is it down for everyone, or just you?

A surprising number of “outages” are local: a VPN, a corporate firewall, a stale DNS cache or a browser extension. Check from somewhere else before you change anything.

  • Load the site on your phone with Wi-Fi turned off.
  • Try a private browser window, which skips cached pages and extensions.
  • Check it from an outside server.
Website down checkerChecks your site from our servers right now and shows the status code, response time and any error.

If it works from outside but not for you, the problem is on your side of the internet. If it's down from everywhere, carry on.

2. Does the domain still resolve?

Before a browser can connect, DNS must turn your domain into an IP address. If that fails, nothing else matters.

bash
dig +short yourdomain.com A     # should print your server's IP address
dig +short yourdomain.com NS    # the DNS servers in charge of your domain

What to look for:

  • No answer at all: the domain may have expired, or its nameservers changed. Check the expiry date with a WHOIS lookup. Expired domains are more common than anyone admits.
  • The wrong IP: a recent DNS change, or a migration that didn't update every record.
  • Different answers from different places: a change is still spreading. It can take up to the record's TTL.
DNS lookupSee every record for a domain (A, AAAA, CNAME, MX, TXT, NS) as public resolvers see it.WHOIS lookupFind the registrar and the exact expiry date of a domain.

3. Can you reach the server at all?

DNS works, so try to open a connection to the web server directly:

bash
nc -vz yourdomain.com 443
  • Connection refused: the machine is up but nothing is listening. The web server or app process isn't running.
  • Timeout: a firewall or security group is dropping traffic, or the machine itself is down.
  • Connected: the network path is fine. The problem is higher up.
Port checkerTests whether a port (443, 80, 5432…) is open from the internet.

4. Is the certificate valid?

An expired or mismatched certificate looks like an outage to visitors: browsers show a full-page warning and most people leave. Check the dates and the names it covers:

bash
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates
SSL certificate checkerShows who issued the certificate, when it expires, which names it covers, and whether browsers trust it.

If it expired, the fix is usually a manual renewal and a reload of the web server. Then find out why auto-renewal failed; there's a whole guide on that.

5. What does the server actually answer?

Ask for the page and look at the status code and timing:

bash
curl -sS -o /dev/null -w "%{http_code} in %{time_total}s\n" https://yourdomain.com/

The status code narrows it down fast:

You seeUsually meansLook at
500The app crashed handling the request.Application logs, the last deploy.
502The proxy reached your app, but it answered badly or died.App process, memory, crash loops.
503Overloaded, or deliberately in maintenance.Load, worker count, maintenance mode.
504The app didn't answer in time.Slow queries, stuck calls to other services.
521–526Cloudflare can't reach or trust your origin.Origin server, firewall, origin certificate.
200, but the page is wrongUp, but broken.Errors in the page, the database, third-party APIs.
HTTP headers & redirect checkerFollow every redirect hop and see the status code and headers at each step. Great for redirect loops.

6. What changed?

Most outages follow a change. Before digging into the server, list what changed in the last few hours:

  • A deploy, a configuration change or a feature flag
  • A DNS edit, a certificate renewal, a new CDN rule
  • A traffic spike: a launch, a newsletter, a bot
  • An outage at a provider you depend on. Check their status pages before your own servers

If a deploy just went out

Roll it back first and investigate second. Getting customers working again matters more than understanding the bug, and the rollback itself tells you whether the deploy was the cause.

7. Is the server out of something?

If nothing changed, the server may have quietly run out of a resource:

bash
df -h          # disk: a full disk breaks databases, logs and uploads
free -m        # memory: watch for the OOM killer in the system log
uptime         # load average compared with the number of CPUs

Also check the database: too many connections and long-running locks look exactly like an app outage from the outside.

8. Tell people while you fix it

A short “We're investigating” on your status page within a few minutes saves you dozens of support emails and buys a lot of patience. You don't need the cause yet, only an acknowledgement and a time for the next update. Here's how to write those updates.

Next time, hear about it first

The worst way to learn your site is down is from a customer. An uptime monitor checks from outside every minute or so and alerts your team the moment it fails, usually before anyone notices. Spot Downtime does exactly that and confirms each failure with a quick retry, so a single dropped packet doesn't wake anyone.

Start monitoring for free: 20 monitors, alerts by email, Slack, Teams and more, and a public status page.

Keep reading