August 8, 2026 · by David Gilbert · 3 min read · Web & E-Commerce
A client's website going down is never convenient, but it has a habit of choosing the worst possible moment — the morning of a big promotion, the day a journalist links to a product page, the exact week traffic was finally building nicely. Here's what I actually do in the first ten minutes of that call, because the instinct to panic helps nobody and the instinct to guess randomly usually makes things worse.
First: Confirm It's Actually Down
Sounds obvious, but a meaningful share of "the site's down" calls turn out to be a single device's cached error, a local network issue, or a DNS problem specific to one internet provider rather than the site itself. A quick check from an independent connection settles this in under a minute and avoids wasting time diagnosing a server that was never actually the problem.
Second: Identify Which Layer Failed
Is the server itself unreachable, or is the server running fine while something on top of it — a plugin conflict, a bad update, a database connection issue — is the actual cause? These need completely different responses, and guessing wrong wastes the most valuable resource in an outage: time. A quick look at server status and error logs usually narrows this down fast, before touching anything else.
Third: Stop the Bleeding Before Finding the Root Cause
If there's a recent change — a plugin update, a new feature, anything deployed in the last 24 hours — rolling that back immediately, even before fully understanding why it broke things, often restores service fastest. Full root-cause investigation can happen calmly afterwards. In the moment, restoring service matters more than fully understanding the failure, and those two goals don't always need to happen in the same order.
Why Panicked Guessing Makes Things Worse
The worst outcome I've seen isn't a long outage — it's a short outage turned into a long one because someone, understandably panicked, started making unrelated changes hoping something would help, without a clear hypothesis. Each random change adds a new variable, making the actual cause harder to isolate rather than easier. Slow and methodical, even under real pressure, beats fast and random almost every time.
What I Tell Clients Afterwards
Every outage, once resolved, gets a specific, concrete answer to "what actually caused this" and "what's changing so it's less likely next time" — better monitoring so we catch it before customers do, a staging environment to test changes before they hit the live site, or simply better backups so a rollback is fast rather than improvised under pressure.
The Preparation That Actually Prevents the Worst Cases
Uptime monitoring that alerts immediately, rather than waiting for a customer complaint to be the first signal. A tested rollback process, so reverting a bad change takes minutes rather than becoming its own emergency. And honestly, realistic expectations — no website is ever at zero risk of an outage, and the businesses that handle them best aren't the ones who've eliminated all risk, they're the ones with a calm, practised process for when it happens anyway.
The Reassurance Worth Hearing
An outage during a big moment feels like a catastrophe in the middle of it. Handled with a clear process rather than panic, it's usually a recoverable, forgettable blip within a day or two — and the businesses that come out of it looking most professional are the ones who communicated calmly and clearly with customers throughout, rather than the ones who somehow avoided ever having an outage at all.