Blog · 24 October 2026
What to do when your web server goes down: a first-hour checklist
Your website has stopped loading. A customer has emailed to say so, or you've just seen a blank page or an error message yourself. The first hour matters. What you do in it decides whether this is a short, well-handled blip or a long, expensive mess.
Print this checklist, save it somewhere that isn't on the affected server, and share it with whoever looks after your site. Work through it in order.
Minutes 0-5: confirm what's actually happening
Before you raise the alarm, make sure the problem is real and find out how big it is.
- Check from a different network. Try your phone on mobile data, not Wi-Fi. If the site loads there, the problem may be your own connection or a local DNS cache.
- Ask someone else. A colleague or friend in another location can confirm quickly.
- Use an uptime checker. Free "is it down for everyone?" tools show whether the site is unreachable globally.
- Note exactly what you see. Is it a timeout, a "502 Bad Gateway", a "503 Service Unavailable", a certificate warning or a blank page? Take a screenshot. Your host will ask.
- Check how much is affected. Is it the whole site, just the checkout, or just the admin area? Does email on your domain still work?
Write down the time you first noticed the problem. You'll want it later.
Minutes 5-15: rule out the quick, boring causes
Many "outages" turn out to be an admin slip rather than a hardware failure. Check these before you panic.
- Domain registration. Has your domain expired? Log in to your registrar and check the renewal date.
- Hosting account status. Look for a suspended account, an unpaid invoice or a usage limit that's been hit.
- SSL certificate. An expired certificate can make a working site look dead to visitors, because browsers show a full-page warning.
- DNS records. Check that your domain still points to the right server. A mistaken edit can take a site offline.
- Recent changes. Did anyone update a plugin, theme, server setting or the site's code in the last day or so? Rolling back a recent change is often the fastest fix.
- Your host's status page. If the provider already reports an incident, you know it isn't your fault and you can stop troubleshooting.
Minutes 15-25: contact your host properly
If the quick checks haven't solved it, raise a support ticket or call. Be specific, because vague reports get slow answers.
Include:
- Your domain name and hosting account details
- The time the problem began
- The exact error message and your screenshot
- What you've already checked
- Whether it's affecting the whole site or part of it
Ask two direct questions: what is the cause, and what is the estimated time to fix? If they can't answer either, that tells you how to plan the next half hour.
Minutes 25-40: tell people before they have to ask
Silence makes an outage feel worse than it is. Even without a fix, communicate.
- Staff: Tell everyone who deals with customers, and agree one short line to use.
- Social media: Post a brief note: "Our website is currently unavailable. We're working on it and will update you shortly."
- Google Business Profile and other listings: Add a temporary notice if you can.
- Email signature or auto-reply: If email still works, a one-line mention helps.
- Phone: Make sure the number customers need is reachable, and say on social posts how else to get in touch.
If you take orders, bookings or enquiries through the site, decide how to capture them in the meantime. A phone number, a spare email address or a simple form on a separate service will do. [Add your own fallback contact method here.]
Minutes 40-50: find out where your backups are
Now is when you discover whether your backup plan is real. Answer these quickly:
- When was the last full backup? Hours, days or months ago?
- Where is it stored? If the backup sits on the same server that's down, you can't reach it.
- Does it include everything? That means files, database, settings and uploaded images, not just one of them.
- Has anyone ever tested a restore? An untested backup is only a hope.
- Who has the logins? Make sure the person who can restore is reachable.
If the answers are "not sure", that's a finding for your after-action notes. For now it shapes your next decision.
Minutes 50-60: decide whether to wait or restore elsewhere
By now you should know the cause, or at least have a straight answer from your host. You have two realistic options:
| Situation | Sensible choice |
|---|---|
| Host gives a firm, short fix time | Wait, keep communicating, and check back at agreed times |
| No clear cause or timescale | Start restoring your latest backup to a different server |
| Data may be damaged or compromised | Restore from a known clean backup, and change passwords |
Whichever you choose, set a time to review. "We'll decide again at [time]" stops hours slipping by while everyone hopes for the best.
After the hour: close it out properly
Once the site is back:
- Check key pages, forms, checkout and login, not just the homepage.
- Clear caches and confirm that DNS and SSL are behaving.
- Tell customers it's resolved.
- Write down what happened, the timeline, what worked and what didn't.
- Fix the gap that made it hurt most, whether that's a missing backup, a slow host or an unclear owner.
How a standby copy changes that hour
Look back at that checklist. Most of the stress comes from the middle: waiting for your host, wondering if the backup works, and deciding whether to rebuild somewhere else.
A standby copy of your site changes this. Instead of hunting for a backup and building a new home for it while customers see an error page, you already have a recent, ready-to-use copy held separately from your main server. The hour becomes shorter and calmer:
- Confirming and ruling out causes still takes a few minutes, but you're no longer relying on the answer.
- Waiting on your host stops being your only option.
- The backup question is already settled, because the copy exists and sits away from the failing server.
- The wait-or-restore decision becomes much easier when restoring is a realistic option rather than a project.
You'd still communicate and still write up what happened. But the pressure drops, and the gap between "site down" and "site back" can shrink considerably. [Add DRSite's specific switchover details here once confirmed.]
DRSite is built for website backup and disaster recovery, so that when something goes wrong, your online presence stays protected. You can see how it works on the DRSite homepage, or start your free trial and set up a standby copy before you need one.
The best time to build your first-hour plan is before the first minute. Save this checklist today, and put a standby copy in place while your site is still up.