Website Outage Recovery Runbook for Small Teams

The site is down. Slack is quiet because it is only three people and nobody owns "the server." Someone texts: is it us or the internet? You open the homepage on your phone and get a white screen or a certificate warning. Panic is optional. A short runbook is not.

This is a practical outage recovery checklist for Canadian small teams without a 24/7 NOC. Adapt it to your host, your DNS, and who has login access.

First five minutes: classify the outage

1. Check from two networks (phone LTE and office Wi-Fi). If only one fails, local DNS or Wi-Fi captive portal.
2. Check DNS: does the domain resolve? Did it change recently? Use a public DNS lookup tool.
3. Check SSL: browser warning about certificate expiry is a different fix than 502 Bad Gateway.
4. Check host status page or support Twitter if your provider publishes incidents.
5. Check recent changes: deploy, plugin update, DNS edit, billing card expired.

Write down the symptom in one line: "502 from origin," "DNS NXDOMAIN," "cert expired yesterday."

Who to wake up

• Hosting support: server down, suspension, disk full, database not running
• Developer/agency: white screen after deploy, PHP fatal in logs
• DNS registrar: domain expired, nameservers wrong
• Email vendor: if the "outage" is mail only (MX separate from web)

Keep a contact card in context.md or your internal wiki: host ticket URL, account number, developer phone.

Hosting-side quick fixes

• Log into panel: is the account suspended for disk or billing?
• Restart PHP-FPM or web server if the host allows one-click restart (VPS SSH: service status)
• Toggle maintenance mode off if someone left WordPress in maintenance accidentally
• Purge CDN/cache if HTML is stale but origin is fine

Read monitoring disk space if suspension says over quota.

WordPress-specific paths

• Enable recovery mode or rename plugins folder via FTP/SSH to isolate a fatal plugin
• Check error_log and Site Health
• Restore last known good backup if you have one you trust (database + files)

See hacked site first 48 hours if defacement or malware is involved, not just downtime.

Communication while you fix

Post a short status on social or email key clients if downtime exceeds 30 minutes during business hours. "We are aware, working with our host, updates in one hour" beats silence. Turn off ad spend if landing pages are broken.

After it is back

1. Confirm checkout, forms, and login if applicable
2. Review logs for root cause (not only symptom)
3. Schedule preventive fix (staging, monitoring, disk cleanup)
4. Write three bullet postmortem: cause, fix, next step

Uptime monitoring helps next time: what to actually alert on.

Canadian hosting angle

Support hours in Mountain or Eastern time matter when your customers are local. Know whether your VM is in Beauharnois, Edmonton, or Toronto for latency tests during recovery. Data residency does not fix DNS typos.

Bottom line

Outages feel chaotic without a runbook. Classify the failure, call the right owner (host vs dev vs DNS), avoid random plugin deletes until you have logs, and communicate early. Practice once on staging so production is not the first drill.

Want Canadian hosting with humans on support when things break? Talk with Swift Host. We help clients through migrations and rough weekends, not only happy-path signups.