WordPress site down? What to do in the first 15 minutes

Most WordPress outages I've worked on weren't hard to fix. They were slow to fix, because the first quarter of an hour went on guessing, refreshing and trying things at random. Recovery time is mostly decided by what you do in the first 15 minutes, and that's something you can plan before anything breaks.

This is the order we work in when an alert fires on a site we manage. Copy it, adapt it, and keep it somewhere you can find at 2am.

Minutes 0–3: confirm it's really down, and for whom

Before touching anything, check the site from outside your own network: a phone on mobile data, an online "is it down" checker, or your monitoring tool's view from several locations. A site that only fails from your office is a different problem from a site that fails everywhere.

Then check what "down" actually means. A timeout, a 500 error, a white screen, a database connection error, a browser security warning and a broken checkout all have different causes. Note the exact error and the time it started. That one line saves a lot of guessing later.

Minutes 3–6: ask what changed

The most useful question in any outage is "what changed?" Most incidents follow a change: a plugin or theme update, an automatic core update, a code deploy, a DNS or CDN change, a new firewall rule, or a hosting change. Check the update history, your deploy log and any messages from your team.

If nothing changed on your side, look at things that change on their own: an expired SSL or domains, a full disk, a database that hit its connection limit, a traffic spike, or a provider having an incident. Check your host's status page before you start rebuilding things.

Minutes 6–10: roll back before you debug

If you found a recent change, undo it first and investigate later. The goal in the first 15 minutes is to get the site back, not to understand the bug.

A plugin update broke it: deactivate that plugin by renaming its folder in wp-content/plugins over SFTP or the file manager, or with WP-CLI.
A theme or code deploy broke it: redeploy the previous version.
You can't tell what broke it: restore the most recent backup from before the problem started, to staging first if you have the time, or straight to production if the site is losing orders.
The disk is full: find what's growing (logs, backups stored on the server, cache folders) and clear space before anything else.

This step is only fast if you already know where your backups are, how long a restore takes and who has the access. If any of those is a question mark, fix that this week, not during an outage.

Minutes 10–15: tell people

Post a short update on your status page or send it to the client or team: what's affected, that you're working on it, and when the next update will be. You don't need the cause yet. Silence makes a 20-minute outage feel like a disaster; a two-line update every 30 minutes makes it feel handled.

Make sure the status page itself doesn't live on the same server as the site. If it does, it goes down at exactly the moment you need it.

After it's back: write it down

Once the site is stable, write a short note: when it started, when it was noticed, when it was fixed, what caused it and what you'll change so it doesn't happen again. Three outages in, those notes usually show a pattern, such as updates on Friday afternoons, a plugin that breaks every few months, or alerts going to the wrong person.

What to prepare before the next outage

Access: hosting panel, SFTP or SSH, DNS and the domain registrar, stored where more than one person can reach them.
Backups: off-server, recent, and restored at least once as a test so you know how long it takes.
Monitoring: uptime from several locations, plus checkout or key-page checks, SSL and domain expiry, and disk space.
Alerts: going to a named person and a backup person, not just a shared inbox.
Status page: hosted somewhere separate from the site.
This checklist: printed or saved somewhere that still works when your site doesn't.

You can't prevent every outage. You can make sure the first 15 minutes are spent fixing it, not working out where to start.