Vendor Risk: What Happens When a Third-Party Service You Depend On Goes Down

Modern applications depend on a growing stack of third-party services — payment processing, email delivery, authentication, maps, analytics — and it's worth asking, honestly, what happens to your product the moment any one of them has an outage, because eventually one of them will.

The uncomfortable audit worth running

List every third-party service your product depends on to function, and for each one, ask what breaks if it's unavailable for an hour. Some answers will be minor — analytics not recording for a bit is rarely a crisis. Others will be severe — if payment processing goes down and your checkout has no graceful failure state, that's a direct revenue and trust problem.

What to actually do about the severe dependencies

• Graceful degradation — a clear, honest message when a dependency is unavailable, rather than a confusing broken page or an infinite loading state.
• Retry logic with backoff for transient failures, so a brief blip doesn't need to become visible to the user at all.
• Monitoring on your dependencies' status, not just your own systems, so you know about a vendor's outage before your own customers tell you.
• For the most critical dependencies, understanding what a fallback or alternative would actually look like — even if you never need it, knowing the plan exists is worth the exercise.

Why this connects to hosting and disaster recovery

This is the same category of planning as your own disaster recovery plan — except the failure originates outside your own infrastructure, which is exactly why it's easier to overlook when choosing hosting and vendors in the first place.

You don't control when your vendors go down. You do control how gracefully your product handles it when they do.

This audit costs an afternoon and usually reveals two or three specific, fixable gaps — far cheaper to find now than during an actual outage, live, with customers watching.