Your website goes down on a Saturday morning. What happens next?

What actually happens when your website goes down?

Usually one of five things, and they're not equally serious. Knowing which one you're looking at tells you who to call and how worried to be.

Work down the list before assuming the worst. A surprising share of Saturday-morning outages turn out to be an expired card on a renewal notice nobody opened.

• The domain lapsed — the .nz renewal failed because the card on file expired. Common, embarrassing, and fixable in minutes if you can still get into the registrar.
• The SSL certificate expired — visitors get a full-screen browser warning. The site is technically fine, but nobody will get past that screen.
• The host is having an outage — nothing you can do except check their status page and wait. Also the least likely of the five on a decent host.
• A deploy or plugin update broke it — something changed on Friday afternoon. This is where a rollback saves you.
• You've been compromised — defacement, spam redirects, or the host has suspended you for sending spam. The only one where restoring the backup alone isn't enough.

How would you even know?

Most NZ small businesses find out when a customer texts them. That means the outage started at 11pm Friday and ran for twelve hours through your busiest booking window before anyone noticed.

Uptime monitoring solves this for close to nothing. A service checks your site every minute from outside your network and texts or emails you when it stops responding. Free tiers cover a single site comfortably, and the paid tiers are a few dollars a month.

• Monitor the page that matters — your booking or checkout page, not only the homepage. The homepage can load fine while the form behind it is broken.
• Set a certificate expiry alert so you get 14 days' warning rather than a browser warning on the day.
• Send alerts somewhere you'll see them on a weekend — a phone number or a team chat, not an inbox you check on Mondays.

Do you actually have a backup you can restore?

This is the question that catches people. Plenty of businesses pay for backups. Far fewer have ever restored one, and a backup that has never been restored is a theory rather than a safety net.

There are a few things to verify, and you can check all of them in half an hour: what is being backed up, where it's stored, and how far back it goes. Files without the database is a broken site. A backup stored only on the same server disappears with the server.

• Files and database together — one without the other doesn't restore a working site.
• Stored somewhere else — a separate provider or region, not the same box the site runs on.
• At least 30 days of history — compromises and slow content corruption often aren't noticed for weeks, and a 7-day window may already contain the problem.
• Restored at least once — to a staging site, on purpose, while nothing is on fire. This is the step everyone skips.

Who do you call, and what do they need?

Write this down now, while it's calm, and keep it somewhere that isn't your website. A one-page document with your domain registrar, DNS provider, host, and developer, plus who holds the login for each.

The reason this matters is that a Saturday outage usually stalls not on the technical fix but on access. Someone has to prove they control the domain, and the person who set it up in 2019 has left. Half an hour spent writing this down is the highest-value resilience work most small businesses can do.

• Domain registrar and the account email — including whether that email address still exists.
• Host and DNS provider — often two different companies, and people frequently assume they're the same one.
• Where backups live and who can trigger a restore.
• Your developer's after-hours terms — agreed in advance, so nobody is negotiating rates at 8am on a Saturday.

What does a sensible setup look like for a small NZ business?

Modest. You don't need enterprise infrastructure to be resilient — you need the boring things done properly. Managed hosting with automatic daily backups held off-server, auto-renewing certificates, uptime monitoring on your key pages, and a deploy process you can roll back.

On a modern stack a lot of this comes free. Sites deployed on platforms like Vercel keep every previous deployment available, so rolling back a bad release is a single action rather than a restore. That difference — minutes versus a lost Saturday — is a real argument for how a site is built, not only where it's hosted.

None of this is glamorous, and none of it matters until the one morning it matters enormously. Start with the two cheapest steps: set up uptime monitoring, and write down who holds what access. If you'd rather have the whole thing designed so outages are recoverable in minutes, that resilience is built into how we approach web applications from the start.