FailoverFailoverBeta
Failover · continuity

Keep running when a provider doesn't.

A plain-language continuity playbook for small orgs — redundancy basics before, an ordered failover during, and a short review after.

Why does a small org need a continuity plan?

01 · before anything breaks

Redundancy basics

Most small-org outages hurt because there's exactly one of everything. Redundancy means a second path is already in place when the first one fails — not scrambled together mid-crisis.

  1. 1Map your single points of failureList the tools you can't operate without: payments, email, your website/CDN, your database, your phone line. Anything with only one provider is a single point of failure.
  2. 2Keep an offline copy of critical dataA weekly export of your donor/customer list, finances, and contacts — stored somewhere that does NOT depend on the same provider — means an outage is an inconvenience, not a loss.
  3. 3Have a second channel for each critical jobIf online intake dies, can you take it by phone or paper? If email is down, is there a text or signal group? Decide the backup before you need it.
  4. 4Write down your provider status pagesBookmark each provider's status page (and the Failover board). In an outage you want to confirm it's them, not you, in seconds.
02 · when something is down

Failover steps

A calm, ordered response beats heroics. Work the list top to bottom — confirm, contain, communicate, then switch over.

  1. 1Confirm it's the provider, not youCheck the provider's status page and the Failover board. If they report an incident, stop debugging your own setup.
  2. 2Contain the blast radiusPause anything that could pile up errors or charge customers twice — scheduled sends, bulk imports, automated retries.
  3. 3Tell the people affectedA short, honest note ("our booking form is temporarily down — call us at …") prevents lost work and frustrated customers. Don't promise a fix time you don't have.
  4. 4Switch to the backup pathMove the critical job to the second channel you set up in step 01: phone intake, secondary provider, or a queue to retry once the provider recovers.
  5. 5Watch for recovery, then catch upWhen the provider clears the incident, re-enable paused jobs deliberately — one at a time — and reconcile anything that queued up during the outage.
03 · after it's over

Learn from it

The cheapest time to improve resilience is right after an outage, while it's fresh.

  1. 1Write a 10-minute recapWhat broke, how long, what you did, what it cost. Plain notes — not a formal report.
  2. 2Fix the one thing that hurt mostPick the single biggest gap the outage exposed and close it this week. Resilience compounds one fix at a time.
  3. 3Re-test your backupsBackups that have never been restored are not backups. Actually restore a recent export to confirm it works.
Pin this

The whole plan in one line: Confirm it's them → contain → tell people → switch to the backup → catch up on recovery. Keep the Failover status board open so you know which providers are affected.

General continuity guidance, not legal, security, or insurance advice. Every org is different — adapt these steps to your own tools and obligations. We won't tell you you're "safe"; we'll tell you what to do next.