Your Site Is Down. Work Out Whose Fault It Is

Somebody messages you at 11am: "Sir, your website is not opening." You type the address, and nothing loads. Your stomach drops, you call whoever built the site, and they don't pick up.

Most of what happens in the next thirty minutes is wasted. People refresh the page eleven times, forward the message to four different WhatsApp groups, and call the hosting company to shout at someone who cannot help until they know the domain name. The outage is rarely the expensive part. The panic is.

This is the checklist. It is in order for a reason — each step eliminates a layer, so by the time you reach the end you know who owns the problem and what to say to them. You need no technical skill to run it. You need a browser and your phone.

Step one: confirm it is actually down

Before anything else, establish that the site is down for other people, not just for you. A surprising share of "the website is down" turns out to be one person's wifi, one person's office firewall, or a page cached in one person's browser from an hour ago.

Do these three things, in this order, and they take under two minutes:

1. Turn off wifi on your phone and load the site over mobile data. Different network, different route to the server. If it loads on mobile data but not on office wifi, the problem is your office — router, DNS setting, or a firewall rule — not your website.
2. Try it in a private or incognito window. This bypasses your browser cache and any logged-in session. If the normal window shows a broken page and incognito shows a fine one, you were looking at a stale copy.
3. Ask one person outside your city to check. A supplier, a cousin, anyone. Some outages are regional — a network route or a content delivery network edge having a bad day in one place.

If all three confirm it, the site is genuinely down. Now you find out which layer failed.

Step two: read what the screen actually says

This is the single most useful thing you can do, and almost nobody does it. The error message on screen tells you roughly which part of the chain broke. Don't screenshot it and forward it without reading it.

Those three-digit numbers are HTTP status codes — standard, publicly documented responses a web server gives. They are not jargon invented to confuse you. A 500 and a 404 are genuinely different problems with different owners, and saying "it's showing 500" to your developer saves twenty minutes of back and forth.

Step three: check the domain before the host

Domain expiry is the outage that embarrasses people most, because it is entirely preventable and it takes the whole business offline — website and email, usually at once. If your staff suddenly cannot send or receive mail on your company address and the site is down at the same time, suspect the domain first. A pure hosting failure rarely kills email on a separate mail provider.

Go to your registrar's website — the company you bought the domain from, which is often not the company that hosts the site — and log in. You are looking for two things: is the domain still registered, and does it still point at your host? If the registration lapsed, renewing usually brings things back within minutes to a few hours, but there is a grace period and then a much more expensive redemption period, so speed matters.

The prevention is dull and free: set the domain to auto-renew, put the card on it that doesn't expire next month, and make sure the registrar's reminder emails go to an address that is not on the domain itself. If the domain dies, so does the warning email telling you it died.

Who actually holds your domain?

If you cannot answer that question right now, that is a finding in itself. Many owners discover during an outage that the domain sits in an ex-employee's personal account, or with an agency they stopped working with in 2019. Fix that on a calm Tuesday, not during a crisis. Our technical support work often starts with simply writing down who holds what.

Step four: ask the host the right question

If the domain is fine and the error points at the server, it's the host's turn. Before you call, open their status page — most hosts publish one — and check whether they have already declared an incident. If they have, you have your answer and there is nothing to do but wait.

If not, raise a ticket rather than only calling. Tickets create a written trail and route to engineers; phone lines route to whoever is free. Include, in one message:

• Your domain name, spelled out.
• The exact error text or status code.
• The time it started, in IST.
• Whether it fails on mobile data too.
• Anything that changed in the last 48 hours — an update, a new plugin, a payment, a migration.

That last line is the one that solves most cases. Outages are rarely random. Something changed. A plugin auto-updated overnight. A PHP version was upgraded by the host. Someone uploaded a 60MB PDF and hit the disk quota. A hosting invoice went unpaid because it was addressed to a former accounts person.

Step five: tell customers before they tell you

While the technical side is being chased, spend four minutes on the commercial side. If you sell online, every minute of silence is a customer assuming you've shut down.

Put a short note on whatever channel still works — your Google Business Profile post, Instagram story, WhatsApp status, the pinned message on your business number. Say what's happening, say what customers should do meanwhile (call this number, order on WhatsApp), and don't promise a restore time you cannot keep. "We're fixing it, orders on WhatsApp meanwhile" is enough. Your social channels are the only part of your presence you still control during a hosting outage, which is an argument for not letting them go dormant.

One caution on search: a short outage is not normally a ranking catastrophe. Google's own guidance has long been that a 503 status code is the correct way to signal temporary unavailability, because it tells crawlers to come back rather than to drop the page. A site that returns errors for days is a different matter. Panicking about SEO in hour one is misplaced; fixing the site is the SEO response.

What not to buy after an outage

The day after a scare, people buy things. Some of it is worth the money. Some of it is sold precisely because you are frightened.

Worth it: real off-site backups, taken daily, stored somewhere other than the server they came from, and — critically — tested by actually restoring one. An untested backup is a belief, not a backup. Also worth it: uptime monitoring that checks your site every few minutes and messages you before a customer does. This costs very little and changes who finds out first.

Usually not worth it: jumping to a much more expensive hosting plan on the assumption that money buys uptime. If your outage was a crashed plugin or an expired domain, a dedicated server fixes nothing. Diagnose first, upgrade second. Equally, be sceptical of a "security hardening package" sold in response to an outage that had no security cause — a 500 error after a theme update is not an attack.

Genuinely uncertain: whether a second, standby copy of your site on a different host is worth maintaining. For a shop doing serious daily revenue online, possibly. For a brochure site, the complexity usually costs more in confusion than the downtime costs in sales. It depends entirely on what an hour offline actually costs you — a number only you can work out.

The half-hour that prevents the next one

Nearly every outage is survivable. What makes them expensive is not knowing who to call, not having a backup, or finding out six hours late because nobody was watching.

Sit down once and write a single page: domain registrar and login owner, hosting provider and account email, who has admin access to the site, where backups live and how old the newest one is, and the renewal dates for the domain and the certificate. Keep it somewhere two people can reach. That page is worth more during an outage than any support contract.

If you don't know half the answers, that's the job to do this month — not after the next 11am message. We can help you map what you have and set up monitoring and backups as part of ongoing support, or review the site itself if it keeps falling over through our web development work. If you'd rather just have someone look at a site that's behaving oddly, get in touch and tell us what the screen says.

Questions we get asked