If your site is down, spend the first twenty minutes gathering facts instead of changing things. Confirm the outage is real, work out whether the problem is the site, the DNS, or an expired domain, screenshot the error, write down what changed yesterday, and send all of that to whoever is responsible.
That is the whole playbook. It sounds slow. It is faster than the alternative, which is an hour of guesswork that adds three new problems on top of the original one. Below is the sequence, in order, written for someone who does not work on websites for a living.
Minutes 1 to 4: confirm it is actually down
A surprising number of outages are not outages. Before you tell anyone the site is down, rule out the three things that pretend to be a site failure.
- Your network. Pull out your phone, turn off Wi-Fi so you are on cellular data, and load the site. If it works there, the site is up and something local is wrong: your office router, your DNS, your VPN, your ISP.
- Your browser cache. Open a private or incognito window and try again. Browsers hold onto old pages and old redirects longer than you would expect.
- One page versus the whole site. Try the homepage, an interior page, and the login page. One broken page is a different problem from a site that will not load at all, and knowing which one you have saves a round trip.
If it fails on cellular data, in a private window, on more than one page, it is genuinely down. Now you have a fact instead of a feeling.
Minutes 4 to 8: work out which layer broke
Almost every outage lives in one of four layers. You do not need to fix the layer. You just need to name it, because naming it routes the problem to the right person immediately.
The site itself. The page loads but shows an error: a blank white screen, "There has been a critical error on this website", a database connection error, a 500 error, or a half-rendered page with no styling. The domain and the server are fine. Something inside WordPress or on the server broke. This is the most common case, and it is usually a plugin, a theme, or an update that went sideways.
DNS. The browser cannot find the site at all: "server not found", "this site can't be reached", a DNS error code. Nothing loads, not even an error page from your site. Something changed in the records that point your domain at your server, or the DNS provider is having a bad day.
The domain. You land on a registrar page, a parked page, or an ad-filled placeholder saying the domain is expired or for sale. The domain registration lapsed. This happens more than anyone likes to admit, usually because the renewal card expired or the notice went to an old inbox. It is also the fastest fix on this list.
The certificate. The site loads but the browser throws a full-page security warning about an invalid or expired certificate. The site is technically up. Visitors will not get past the warning, so treat it as down.
One useful tell: check whether your email still works. If email on the same domain also stopped at the same moment, you are probably looking at DNS or the domain, not the website. If email is fine and only the site is broken, look at the site.
Minutes 8 to 10: screenshot everything before you touch it
Take a full screenshot that includes the browser address bar, so the exact URL is visible alongside the exact error. Copy the error text verbatim if you can select it. Note the time you first saw it, and note the time you last saw the site working.
This takes ninety seconds and it is the single most useful thing a non-technical owner can do. Error messages change. Caches clear. A site that shows a database error at 9:04 may show a generic 500 at 9:20, and the first message was the one that named the actual problem. If someone else reported it, ask them for a screenshot too, and ask what device and network they were on.
Minutes 10 to 12: change nothing
This is the part people get wrong, and it is worth being blunt about. In the first twenty minutes, do not:
- Deactivate plugins one at a time to see what happens.
- Reinstall WordPress, or update everything "to be safe".
- Edit or delete DNS records to see if it helps.
- Restore a backup over the live site before anyone has looked at the failure.
- Run a security plugin's repair or reset tool.
- Buy a new hosting plan in a panic.
Every one of those changes the crime scene. A restore, in particular, can quietly overwrite the evidence and the last few hours of orders or form submissions at the same time. Random plugin deactivation on a live site tends to turn one broken page into a broken checkout, a broken form, and a broken layout, and now nobody knows which symptom belongs to the original fault.
There is one exception. If you are certain a specific change caused it, because you installed a plugin four minutes ago and the site died on the next page load, say so clearly in your report. That is information, not a fix. Let the person who can see the server logs undo it.
Minutes 12 to 16: write down what changed in the last 24 hours
Outages are rarely spontaneous. Something almost always moved. Sit down and list what you know, even if it feels irrelevant.
- Plugin, theme, or WordPress updates, automatic or manual.
- A new plugin, integration, tracking script, or chat widget added.
- Anyone editing pages, templates, or settings, including a contractor or agency.
- A developer pushing changes.
- Emails from your registrar, host, or card issuer, including failed payment notices.
- A traffic spike, a campaign launch, or a newsletter that went out.
- Anyone else with admin access who might have done something and not mentioned it.
Check the trash folder in your email while you are at it. Expired-card notices from registrars have a talent for landing in spam. This kind of change log is also the reason routine website maintenance matters: when updates are applied deliberately rather than at random, the list of suspects is short.
Minutes 16 to 20: send one email with the facts
Send it to whoever is actually responsible for the site, and send it once. Emailing your host, your developer, your registrar, and your marketing agency simultaneously produces four partial investigations and a lot of contradictory advice.
Put the domain and the words "site down" in the subject line. In the body, include the exact URL that fails, the exact error text, the screenshot, the time it started, the time it last worked, which layer you suspect and why, whether email on the domain is also affected, what you already checked, what changed in the last 24 hours, and a phone number where you can be reached.
That email will get a faster and better answer than "site's down, please help". It gives the engineer everything they would otherwise have to ask you for, and it removes an hour of back and forth from the front of the fix.
What a good host does when you report it
You should expect an acknowledgment from a person, not a ticket number and silence. Then you should expect them to reproduce the failure themselves, look at the server and error logs, identify which layer broke, and tell you in plain language what happened and what they are doing about it.
If the fix requires rolling back, they should have a recent, verified copy to roll back to. We take twice-daily off-site backups with 30-day retention, and we verify them, because an unverified backup is a guess. That is the difference between "we can restore you to this morning" and "we hope this file opens". We have written more about how that works in backups, monitoring, and recovery.
You should also expect a short, honest explanation afterward: what broke, why, and what changes so it does not happen the same way twice. Not a postmortem document. A paragraph from the person who fixed it. Most of the outages we see on inherited sites trace back to something that was never anyone's job to watch, which is the quiet argument for calmer website operations in general.
If nobody is responsible for your site right now
Sometimes the honest answer to "who do I email" is "nobody". The developer who built it moved on. The host answers with a knowledge base article. That is a bad position to be in at 9am with a phone ringing.
We do emergency website help for sites we do not host. During business hours we triage within the hour, tell you what is actually wrong, and quote before we do anything billable. Work outside a hosting plan is $95 an hour, always quoted first, so nobody ends up surprised by an invoice on top of a bad morning. If it turns out the underlying problem is the hosting itself, we will say so, and migrations are free.
Frequently asked questions
How do I tell whether it is my site or just my internet?
Load the site on your phone with Wi-Fi turned off, so you are on cellular data, and try again in a private browser window. If it works on either, the site is up and the problem is on your end: your router, your office network, your VPN, or a cached page in your browser.
Should I restore a backup as soon as the site goes down?
Usually not, and not in the first twenty minutes. A restore can overwrite the evidence of what broke along with any orders, form submissions, or edits made since the backup ran. Find out what failed first. If a restore is the right answer, it will still be the right answer ten minutes later.
Can you help if Hosterr does not host my site?
Yes. Emergency help is available to non-customers, with triage within the hour during business hours. Send the domain, the error, a screenshot, and what changed recently to our contact page and a real engineer will look at it. There is no obligation to move your hosting afterward.
