Handling a Website Emergency Calmly

Website emergencies are rarely technically difficult. They're difficult because they happen at a bad time, with people watching, and the pressure pushes you toward the two worst instincts: changing several things at once, and guessing.

Here's a sequence worth having written down before the day you need it.

1. Establish what is actually broken

"The site is down" is a report, not a diagnosis. Check, in this order:

• Does it load for you? On another network? On a phone on cellular?
• Is it down, slow, or serving an error page? Which error?
• Everything, or one page?
• When did it start? What changed around then?

Third-party checkers are useful here — they distinguish "down for everyone" from "down for the person who called you," and those need different responses.

2. Communicate before you fix

Ninety seconds, and it changes the entire experience for everyone else: "We're aware the site is down, we're looking at it now, and I'll update you within thirty minutes."

Silence during an outage is what turns a technical problem into a trust problem. Set an update interval and keep it, even when the update is "still working on it."

3. Check the boring causes first

In rough order of how often they're the answer:

• Expired domain or SSL certificate. Instantly identifiable and instantly fixable.
• The host is having an incident. Check their status page before debugging your own code.
• A recent change. Update, deployment, plugin, DNS edit. What happened in the hour before?
• Disk full, or resource limits hit. Common after a traffic spike or runaway logs.
• A DNS change that propagated.

A large share of emergencies end at one of those five.

4. Change one thing at a time

The panic instinct is to deactivate all the plugins, clear every cache, roll back the deploy, and restart the server simultaneously. If the site comes back, you've learned nothing and it will happen again.

One change. Test. Note what you did. Next change.

Keep a running note as you go — what you tried, what happened. It's your incident record and, at 2 a.m., your memory.

5. Restore rather than debug, when the clock matters

If it's revenue-critical and you have a known-good backup, restoring is often the right first move. Get the business back online, then diagnose from a copy at your own pace.

Preserve the broken state before you overwrite it. You will want it.

6. Write it down afterwards

Within a day: what happened, when, why, how it was fixed, and what would prevent it. No blame — the useful output is a change, not a culprit.

Then actually make one change from that list. Monitoring that would have caught it sooner, an expiry reminder, a staging step, a backup you now test. An incident that produces no change is an incident you're going to have again.

The preparation that makes all of this easier

Before anything is broken, write down: who to call at the host, where the backups are and how to restore them, who controls DNS and the domain, and what "critical" means for this business.

One page. It converts a crisis into a procedure — which is the whole difference between a bad hour and a bad week.