What to Do the Moment Your Website Goes Down (A Business Owner’s Action Plan)

Your website going down triggers a very specific kind of panic — the kind where every minute feels like it’s costing money, customers are potentially seeing an error page right now, and you’re not entirely sure whether the problem is on your end, your host’s end, or somewhere in between. The businesses that handle this well aren’t the ones who never experience downtime. They’re the ones who already know exactly what to do in the first five minutes.

Having 24/7 support and a clearly enforced uptime SLA in place before an outage happens is what actually makes this checklist executable in real time, instead of leaving you improvising while your site is offline.

Step 1: Confirm It’s Actually Down (Not Just You)

Before anything else, check whether the outage is real or local to you. Use a third-party tool like DownForEveryoneOrJustMe or a similar service to confirm the site is down for other visitors, not just your own connection or a DNS caching issue on your device. This single step saves you from launching a full incident response over what might be a five-minute local network issue.

Step 2: Check Your Provider’s Live Status Page First

Most established hosting providers maintain a live status page showing real-time incident data. Check this before opening a support ticket — if there’s a known, already-being-addressed incident, you’ll get faster, clearer information than waiting in a support queue, and you can immediately gauge scope and expected resolution time.

Step 3: Open a Support Ticket With Specifics, Not Panic

If it’s not a known incident, contact support immediately with specific details: exact time the issue started, any error messages your team or customers are seeing, and what (if anything) changed recently on your end — a deployment, a plugin update, a DNS change. Specific information gets you a faster, more accurate response than a general “the site is down, please help.”

Step 4: Communicate With Your Customers Proactively

If the outage is likely to last more than a few minutes, get ahead of customer confusion. A short status update on social media, a status page of your own, or an autoresponder on support email — even a simple “we’re aware of an issue and working on it” — measurably reduces the volume of frustrated, duplicate support inquiries you’ll otherwise field during and after the outage.

Step 5: Document Everything for Your SLA Claim

If your hosting provider has a guaranteed uptime SLA, downtime beyond the agreed threshold may entitle you to service credits — but only if you can document it. Note the exact start and end time of the outage, any confirmation from the provider’s status page or support communication, and file your claim within whatever window your SLA specifies, since many SLAs require claims within a defined period after the incident.

Step 6: Run a Post-Incident Review

Once resolved, spend 30 minutes reviewing what happened: was it a hosting-side issue, a code deployment issue, or a third-party service failure? This determines whether your next action is a conversation with your hosting provider, a change to your deployment process, or nothing at all beyond noting it happened. Skipping this step is how the same type of outage repeats months later.

FAQs

1. What’s the very first thing I should do when my website goes down? Confirm it’s actually down for other visitors using a third-party checking tool, not just experiencing a local issue on your own device or network.
2. Should I contact support immediately, or check something first? Check your hosting provider’s live status page first — if it’s a known, already-being-addressed incident, this often gives you faster and clearer information than opening a new ticket.
3. How do I know if I’m entitled to SLA compensation for an outage? Compare the documented outage duration against your SLA’s guaranteed uptime threshold. If the shortfall exceeds what’s allowed, you’re typically entitled to a defined service credit — document the incident carefully to support your claim.
4. Should I tell my customers the site is down, or wait until it’s fixed? Proactive communication, even brief, reduces confusion and duplicate support inquiries. Waiting until resolution often leads to a larger support burden during the outage itself.
5. What information should I document during an outage for an SLA claim? The exact start and end time, any status page confirmation from the provider, and details of your support communication — most SLAs require this documentation within a specific claims window.
6. What should happen after the website is back up? A short post-incident review to determine the root cause — hosting-side, code-related, or third-party — so you can prevent a repeat, rather than treating the incident as fully closed once the site is simply back online.