What to do when your business website goes down

A down website is one of the few software problems that feels personal.

Customers cannot book. They cannot pay. They message you on WhatsApp asking why the link does not work. Google still shows your business, but the site behind it is blank, certificate-warned, or stuck on an old error page.

The panic is rational. The usual mistake is not waiting too long. It is fixing the wrong thing.

The first job is not to redesign anything. It is to restore the customer path and preserve enough clues to find the real cause.

Start with what broke, not what you wish you had built

Before you open a site builder, rewrite copy, or ask an AI tool to rebuild the whole app, write down what actually failed:

• Does the domain load at all?
• Does the homepage load but checkout or M-Pesa fail?
• Did business email stop working too?
• Did this start right after a change: new host, new developer, DNS edit, plugin, deploy?
• What exact error do customers see, and on which device or browser?

Those answers tell you whether you have a hosting problem, a DNS problem, an integration problem, or a code problem. They are not the same fix.

Check the boring infrastructure first

Most small business outages trace back to a short list:

Domain and DNS. Unpaid renewal, nameservers pointing at the wrong place, an A record edited incorrectly, or a recent migration still propagating.

Hosting and SSL. Suspended account, expired certificate, exhausted disk space, or a deploy that never finished.

Third-party integrations. M-Pesa callback URL changed, form provider disconnected, booking widget expired, email routing broken after a domain move.

Recent changes. A freelancer "just moved the site," someone edited DNS at the registrar, or an AI coding tool shipped a change nobody tested on the live domain.

If the site worked yesterday and nobody touched code, suspect DNS, hosting, or SSL before you suspect the homepage design.

Take screenshots before changing anything. Copy the exact error text. If you can see DNS records, export or screenshot them before editing. A messy record of the outage is still better than trying to remember what the screen said after three rushed fixes.

What not to do while you are panicking

Do not rebuild the whole site because the homepage is blank. You may be one DNS record away from recovery and a rebuild adds weeks.

Do not let an AI coding tool rewrite five files because one checkout button broke. That is how a small outage turns into a debugging loop.

Do not change three things at once. If you edit DNS, switch hosts, and redeploy on the same afternoon, you will not know which change fixed or worsened the problem.

Do not ignore the customer-facing workarounds. Update your Google Business Profile hours line, pin a WhatsApp status, and tell people how to reach you while the site is down. Recovery includes communication, not just tech.

Do not hand permanent admin access to the first person who says they can fix it. Use scoped access where possible, change temporary passwords after the job, and keep the domain registrar under the business owner's control.

The paths that usually need an engineer

Call for help when:

• You do not know where the domain, hosting, or DNS live
• Email, the site, and payments all broke at once after a migration
• The site loads but M-Pesa, booking, or client intake fails in production
• You have an AI-built app and every fix creates a new bug
• You need the site back today and nobody on the team knows the stack

That is different from wanting a better design next month. Emergency rescue is about restoring service and finding the root cause.

You can often update customers, check whether the domain is paid, and confirm whether email is affected yourself. You probably need engineering help when the failure crosses systems: DNS plus hosting, site plus M-Pesa, app plus deployment, or anything where a bad fix can make recovery harder.

What a rescue engagement looks like

When a small business brings me a down site or broken integration, the first job is triage, not a sales pitch for a rebuild.

I want to know:

1. The domain and what changed recently
2. Where the site is hosted and who has access
3. What customers are trying to do that is failing
4. Whether email, M-Pesa, or booking broke with the site or separately

Then the work is straightforward: reproduce the failure, check domain/DNS/hosting/integration paths, make the smallest fix that restores service, and leave a short note on what broke and what to watch next.

The best outcome is boring: the site is back, the payment or booking path works, and you know which owner controls each part of the stack. If the root cause was a fragile deploy, expired billing, or unclear access, that gets written down so the same outage does not repeat next month.

If the site needs ongoing care after that, monthly maintenance beats repeated panic. If the underlying app was AI-built and fragile, a production-readiness review may be the next step once customers can reach you again.

If your site, domain, email, or M-Pesa link is down and you need it fixed now, send a brief. For productized triage and small critical fixes, see /launch. For ongoing hosting and priority response when something breaks, Always On on the same page is usually the better fit after the first fire is out.