Your Vendor's Uptime Is Your Uptime: A Dependency Risk Framework

When AWS, Stripe, and Shopify all had outages within days of each other, none of the affected merchants or businesses could have prevented it — the exposure is structural, tied to depending on the provider at all. Here's a practical framework for thinking about, and actually managing, that kind of dependency risk.

The Framework: Classify, Don't Just List, Your Dependencies

• Tier 1 — critical path, no workaround: an outage stops your core business function entirely (e.g., your payment processor)
• Tier 2 — degraded but functional: an outage removes a feature or slows you down, but the core business keeps operating
• Tier 3 — non-critical: an outage is inconvenient but has no meaningful business impact

Most teams have a mental list of dependencies but haven't actually tiered them this explicitly — which means resilience investment tends to be reactive (after an outage hurts) rather than proactive (planned in advance for the dependencies that actually warrant it).

What to Do for Each Tier

• Tier 1 — invest in graceful degradation specifically: queuing, clear customer communication, delayed processing — the goal isn't preventing the outage, it's not failing completely and silently when it happens
• Tier 2 — document the degraded-mode behaviour so it's a known, acceptable trade-off rather than a surprise when it happens
• Tier 3 — genuinely fine to accept the risk as-is; spending resilience budget here is usually not worth it

The Real Point of This Exercise

You will never eliminate dependency risk — every business depends on infrastructure it doesn't control. The value of this framework isn't prevention, it's making a deliberate, documented decision about which dependencies get real resilience investment and which don't, instead of discovering the answer for the first time during an actual outage.