Vendor Outage Runbook for Small Teams (When the Outage Isn't Yours)

Some of the worst hours in a small team's year are the ones where your code was fine: a cloud region, a payments provider, or a DNS vendor was down, and your status page said nothing for two hours because "it's not our outage." It is your outage the moment a customer touches your product and it doesn't work. The runbook has four parts: classify fast, degrade deliberately, communicate early, and harvest the dependency list.

1. Classify in 10 minutes: yours, theirs, or both

The first mistake is debugging as if the outage were yours. The second is assuming it's the vendor's and shipping "all systems operational" while your own queue silently fills. Do this instead:

Signal	Points to
Vendor status page degraded + your errors started within the same window	Theirs (probably) — confirm with one canary request through a second path
Vendor green, your errors rising	Yours — switch to your own incident process
Vendor degraded AND your errors predate their window	Both — fix yours first; theirs may mask it

Write down the timestamps. They settle the "whose outage was it" argument in the retro before it starts.

2. Degrade deliberately (or decide to wait)

Every critical vendor needs a pre-decided answer to one question: what do we do while it's down? Pick one of three postures and say it out loud:

Wait: nothing you can do; post an honest status update and a next-update time. Fine for short outages, dangerous for silent ones.
Degrade with a feature flag: queue writes for later, serve cached reads, disable the one feature that depends on the vendor. Customers prefer a working 80% to a broken 100%.
Fail over: only works if the second provider was configured in peacetime. An untested failover is a second outage with extra steps.

If you don't know which features depend on which vendors — that's the finding. See the DR plan template.

3. Communicate before customers ask

Two hours of vendor outage costs less trust than two hours of silence. The pattern that works:

First update in 15 minutes, even if it says nothing new: "We're aware of an issue affecting login, caused by an outage at our auth provider. Next update in 30 minutes." A named vendor buys you credibility; a vague "some users may" burns it.
Update on a clock (every 30–60 min) whether or not anything changed. Silence reads as "nobody is working on it."
The all-clear names the cause and the lesson. One sentence on what you'll change keeps the trust you just spent.

The fill-in-the-blanks version is here: status page communication template.

4. Harvest the dependency list (this is the real deliverable)

Every vendor outage is a free audit of your architecture. Within a week, write down:

The dependency map you just discovered by fire — every feature that broke, and the vendor behind it. Keep it next to the runbook; it ages well.
Which dependencies deserve a plan: any vendor whose outage takes a core feature down. For those: a degrade mode, a failover, or an explicit "we accept this risk" decision signed by someone.
Which vendor promises you never checked: SLA/credits clauses only matter if you log the outage windows when they happen. Ten minutes now, real credits later.
The alert you're adding: canary checks through each critical dependency, so next time your monitoring says it first, not the vendor's own status page.

5. The mistakes that make vendor outages worse

Debugging your own stack for an hour because "vendor pages are often wrong." Sometimes they are — verify with one cross-check, then stop.
Silence "until we know more." Customers fill silence with churn. A timestamped "we know, it's the provider, next update at :30" is worth more than a perfect diagnosis.
No degrade mode anywhere. If every feature hard-depends on one vendor, the outage is yours regardless of whose logo is on the error.
Skipping the post-outage note because "we did nothing wrong." The dependency list you capture is the only part of this outage you'll be glad you kept.

Takeaways

Classify in 10 minutes: vendor status + your error timeline, written down with timestamps.
Degrade deliberately — wait, flag it off, or fail over; decide out loud which one.
Communicate on a clock: first update inside 15 minutes, named vendor, next-update time promised and kept.
Harvest the dependency list — it's the free audit the outage paid for.

---

The Ops Starter Kit ($14) includes the severity matrix and comms templates that make vendor outages survivable, and Vol. 2 ($27) adds the DR plan and evidence log for the review after. Launch week: 20% off any paid kit with code HIVE20 at checkout (ends Sep 11, 23:30 ACST).

The runbook tells you what the vendor outage means for you; the degraded mode playbook is the pre-written answer for what your product does while it lasts — the reduced mode, the switch, and the banner, chosen on a calm afternoon instead of improvised at 2am.

This runbook handles the day a vendor breaks. The single-point-of-failure audit makes sure no vendor is a total outage: five passes, a six-column register, and the four decisions — eliminate, duplicate, document, accept.

Related: the supplier concentration map tells you which outage hurts before it happens; this runbook is the 48-hour playbook for the day one of those mapped suppliers actually stops delivering. the critical spare parts list is what the shelf holds before the outage — the parts whose real lead time is longer than your downtime tolerance.

Put this to work. The Ops Starter Kit bundles the highest-leverage templates — incident response, runbooks, onboarding, checklists — into one download ($14).

Free start: grab the First 30 Minutes incident-response checklist, or get the free template library by email.

Need all of it at once? The Ops Mega Bundle collects all five ops kits in one download — $49.