My Website Is Down — A Step-by-Step Checklist

Step 1: Is It Actually Down?

A surprising share of "the site is down" turns out to be one person, one network, or one browser. Establish which before you touch anything.

• Open the site on mobile data with Wi-Fi off. If it loads, the site is fine and your network is the problem.
• Try a private window. If that works, you are looking at a cache or cookie issue on your machine, not an outage.
• Use an external "is it down" checker, which tests from a different network entirely.
• Ask someone in another country. Geographic blocks and regional routing problems are invisible from where you are sitting.
• Check your hosting provider's status page before doing anything else. If they are having an incident, everything below is wasted effort.

Step 2: Read What the Screen Says

The message on screen is the single most valuable clue available, and it is routinely skipped over. Different messages point at completely different parts of the stack.

Step 3: Check the Four Usual Suspects

Across most outages, four things account for the overwhelming majority. Check them in this order — they take a couple of minutes between them.

• Domain expiry. It sounds too simple to be the answer and it is the answer far more often than anyone expects. A public WHOIS lookup shows the expiry date instantly. An expired domain takes a site down completely and no amount of server troubleshooting will help.
• Hosting account expiry or suspension. Unpaid invoices, exceeded resource limits and policy suspensions all take a site offline. Log into the billing panel rather than assuming.
• SSL certificate expiry. The site is up but every visitor gets a full-page security warning, which is functionally the same as being down. Certificates last 90 days on many free providers and auto-renewal fails silently more often than people realise.
• Disk full. Once the disk is full nothing can write — not the database, not the session files, not even the log that would tell you what went wrong. It produces symptoms that look like everything else on this list.

Step 4: Undo Whatever Changed Last

If the four suspects come back clean, the next question is what changed. Sites very rarely break while nobody is touching them — something almost always happened just before.

Think back over the last twenty-four hours: a plugin or theme update, a deployment, a PHP version change, a new DNS record, an edited .htaccess, a firewall rule added during unrelated work. Each of these is a plausible cause and each is reversible.

Reverse the most recent change first and test. If more than one thing changed, undo them one at a time in reverse order rather than all at once — otherwise you will get the site back without ever learning which change broke it, and you will make the same mistake again.

If you have a backup from before the change and the site is losing money by the minute, restoring is usually the fastest route back to working. Diagnose afterwards on a copy, when there is no clock running.

When to Contact Your Host

Some problems are simply not yours to fix, and recognising them early saves an hour of frustration.

Contact the host when every site on the account is down at once, when the control panel itself is unreachable, when the error points at a service you cannot restart on shared hosting, or when the status page shows an incident. In all of these you have no lever to pull.

When you do write in, include what actually helps: the exact error message, the time it started, what you had changed beforehand, and confirmation that you tested from a second network. A ticket that says "my site is down" will get a reply asking for exactly that, which costs you another round trip.

A reasonable rule: if you have worked through this checklist and still do not know which component failed, that is the moment to ask rather than to keep changing things.

Reducing the Odds of a Next Time

• Turn on uptime monitoring. Finding out from a customer is the expensive way to learn your site is down.
• Turn on auto-renewal for the domain and set a calendar reminder anyway. Payment methods expire.
• Automate certificate renewal and monitor that it actually ran. Silent renewal failure is a classic.
• Test your backups by restoring one. An untested backup is a hope, not a plan.
• Update plugins and core on a staging copy before production.
• Watch disk usage, and set an alert at 80% rather than discovering it at 100%.
• Keep a short written record of changes. When something breaks, "what changed" is the fastest question to answer and the hardest to reconstruct from memory.