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.
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: 30% off any paid kit with code HIVE-LAUNCH30 at checkout (ends Sep 11, 23:30 ACST).