Third-party outages require a slightly different response from failures in systems you operate. Your team cannot repair the vendor, but it can identify the customer effect, reduce harm, communicate clearly, and choose a fallback.
Identify the dependencies that matter
Start with the customer paths your company cannot operate without: sign-in, checkout, support, deployment, communications, and data processing. For each path, list the external services involved.
Record an owner, business impact, approved fallback, and vendor support route. A long inventory without ownership will not help during an incident.
Define severity from customer effect
Use the same severity model as your other incidents. Base it on affected customers, lost functionality, financial exposure, and recovery options. The size or reputation of the vendor should not determine severity.
Route alerts to the responsible team
Combine application alerts with vendor notices in the channel used by the owner. Avoid sending every provider update to every engineer; that makes important changes easier to miss.
Write short runbooks
A useful runbook answers:
Example: payment provider unavailable
- Confirm errors in checkout telemetry.
- Check the provider notice and support case.
- Decide whether to queue orders, offer another method, or stop checkout.
- Publish a customer update that describes your service, not speculation about the vendor.
- Record the start time, affected transactions, decisions, and recovery time.
Exercise the plan
Run a tabletop exercise for one critical vendor. Have the owner walk through detection, fallback, communication, and recovery. Update the runbook where people had to guess. Repeat after major architecture or staffing changes.
Keep the plan small enough to use
The plan should make ownership and the next decision obvious. Maintain the dependency list, test the highest-impact runbooks, and review real incidents for gaps.