Your site is down and your heart rate is up. Here’s the good news: most outages are one of four boring things — DNS, hosting, a recent change, or an expired card — and fifteen minutes of orderly checking finds which one. This is the checklist we run when a rescue call comes in; work it top to bottom and you’ll either have the site back or know exactly who to call and what to tell them. (There’s a longer, why-this-happens version in Field Notes.)

Confirm it’s actually down (and for whom)

“Down for me” and “down” are different problems. Check from outside your own network first — downforeveryoneorjustme.com or your phone with wi-fi turned off. Then ask the site directly what it’s saying:

curl -I https://yoursite.com

A 200 means the site is answering and the trouble is between it and you (your DNS, your VPN, your office network). No response at all, a timeout, or a 5xx means it’s really down — keep going.

Check the obvious billing and expiry suspects

Nobody wants this to be the answer, and it very often is. Domains expire, cards expire, hosts suspend. Check the domain first:

whois yoursite.com | grep -i "expir"
dig +short yoursite.com

An expired domain or a dig that returns nothing points at registration or DNS, not the server. Then check the inbox (and spam folder) for the account that pays for hosting — suspension notices usually arrived three warnings ago. Renewing a lapsed domain in the grace period fixes this one same-day.

Read the error you’re actually getting

The error on screen is the map. A 502/503 means the server is up but the application behind it isn’t — often a crashed process or a traffic spike, and often temporary. A 500 means your code hit a fatal error. A white screen is a 500 with the lights off. A browser “server not found” is DNS. An “expired certificate” warning is HTTPS renewal, not an outage. For a 500, the specifics are in the logs — here’s how to find and read them — and one log line beats an hour of guessing.

Check your host’s status page

Before assuming it’s your fault, check whether it’s theirs. Every serious host runs a status page (search “your host status”), and if there’s an incident posted for your region, your job changes from fixing to waiting — put the kettle on and skip to monitoring the incident. No posted incident doesn’t clear them, but a posted one clears you.

Roll back the last change if there was one

If the site went down right after somebody changed something — an update, a new plugin, an edit to a config file — the fastest fix is reverse. Restore the backup from before the change, or roll back the deploy, and get stable first; diagnosis can happen after, on a copy, with coffee. This is exactly the moment a backup that actually restores pays for itself.

Escalate with the details that get fast answers

If you’re twenty minutes in and still down, open a ticket — but a good one. Include: the exact error (paste the curl -I output), when it started, what changed recently (or “nothing”), and what you’ve already ruled out. That’s the difference between “have you tried clearing your cache” and a real engineer looking at a real problem.

Verify it’s really fixed: load the site from your phone off wi-fi, log in, and click one page that matters — the contact form, the cart. Then do future-you a favor and set up uptime monitoring, so the next outage texts you before a customer does.