Be ready before your website goes down.

1. 1 Know what matters

   Identify the customer-facing pages and services whose failure someone would notice first.

   • List the pages customers rely on most: the home page, sign-in, sign-up or checkout, and any booking or contact form.
   • Add the services behind them that aren’t web pages: your API, your mail server, anything a customer’s request passes through.
   • For each one, write down what “working” means — not just “the server answers”, but “the page shows the content it should”.
   • Note the parts you don’t run yourself: domain and DNS, hosting, certificates, payment and email providers.
   • Mark the few whose failure costs money or trust fastest. Those come first in every section below.

2. 2 Choose checks that mean something

   Pick meaningful checks for each critical item, and be honest about what they can’t see.

   • Match each check to the failure you care about: “is it reachable”, “is it showing the right content”, “is the mail or other service port answering”.
   • Check from outside your own network, and from more than one location, so a local glitch isn’t mistaken for an outage — and a regional one isn’t missed.
   • Choose a check frequency that matches how quickly you’d want to act.
   • Write down the coverage limits: pages behind a login, slow-but-working pages, third-party widgets, background jobs. A known gap is a decision; an unknown one is a surprise.

3. 3 Name who gets alerted

   Every critical check needs a primary alert owner and a backup.

   • Primary alert owner:
   • Backup alert owner:
   • Send critical alerts by at least two routes (for example email and SMS), so one blocked channel doesn’t silence them.
   • Agree when the backup takes over: no acknowledgement from the primary within an agreed time, holidays, time off.
   • Send a test alert and confirm that both people actually received it.

4. 4 Plan the first five minutes

   Decide now what happens between “an alert fired” and “someone is fixing it”.

   • Incident lead: the first owner to respond leads until they hand over, explicitly, to someone else.
   • Confirm it’s real: open the page yourself, ideally from a different network or device.
   • Start an incident log straight away — a shared doc or chat thread is fine. Note when it was noticed, what you saw, and every change you make, with the time.
   • Decide who updates customers, and where: status page, social account, support auto-reply or email. Keep a short holding message ready to adapt.

5. 5 Keep recovery within reach

   Make sure the way back doesn’t depend on one person or on the site that’s down.

   • Know how to roll back the last deploy or configuration change, and who is allowed to do it.
   • Check that at least two people can sign in to hosting, DNS, the domain registrar and any CDN — with working credentials and two-factor devices, kept in a shared password manager.
   • Keep a one-page runbook for each critical service: where it runs, how to restart it, where the logs are, and how to reach the vendor’s support.
   • Store the runbook somewhere you can still open when your own website, email or network is down.

6. 6 Verify recovery and follow up

   “It seems fine now” isn’t the end of an incident.

   • Call it resolved only when the checks that alerted you are passing again and a person has walked through the critical journey, such as signing in or checking out.
   • Tell customers it’s resolved, through the same channels you used for the updates.
   • Within a few days, write a short, blame-free review: what happened, how you found out, and what slowed you down.
   • Give every follow-up action a named owner and a date, and check them at your next review of this list.

Review this list whenever people change roles or you add a critical service, and at least once a quarter. Website Outage Readiness Checklist by BinaryCanary — www.binarycanary.com/outage-readiness-checklist