How to Explain a Third-Party Vendor Outage to Customers in English
Learn how to communicate a service disruption in English when the root cause is a third-party vendor outage — being transparent without shifting blame or sounding evasive.
When an outage is caused by a third-party vendor — a cloud provider, a payment processor, an email service — you still own the customer relationship, even though you don’t control the fix. Getting the English right here is a balancing act: you need to be honest about the cause without sounding like you’re pointing fingers or hiding behind “it’s not our fault.” This guide covers how to communicate clearly during and after this kind of incident.
Key Vocabulary
Upstream dependency — a third-party service your system relies on, whose failure can cause your own service to degrade or fail. “Our checkout flow depends on an upstream payment processor — when their API became unavailable, checkout failures followed directly.”
Downstream impact — the effect on your users or systems caused by an upstream failure. “The downstream impact was that roughly 15% of checkout attempts failed for approximately 40 minutes.”
Root cause (external) — being specific that the underlying cause originated outside your own systems, without using it as an excuse to avoid responsibility for the user experience. “The root cause was an outage at our cloud email provider — while we don’t control their infrastructure, we are responsible for how our system handles that kind of failure gracefully.”
Graceful degradation — designing a system so that when a dependency fails, some functionality still works instead of everything failing completely. “Because of graceful degradation, users could still complete purchases with saved payment methods even while the new-card verification service was down.”
Post-incident action items — concrete steps your team is taking as a result of the incident, even when the cause was external, showing you’re not just waiting for the vendor to fix it and moving on.
Communicating During the Incident
- “We’re currently experiencing a service disruption caused by an outage at one of our infrastructure providers. Our team is actively monitoring the situation and working on mitigations.”
- “While the underlying issue is with a third-party service we depend on, we understand the impact on you is the same regardless of the cause — we’re treating this with full priority.”
- “We don’t have an ETA from the vendor yet, but we’ll post an update within the hour regardless of whether the situation has changed.”
Explaining After Resolution
- “The service disruption between 2:14pm and 2:53pm today was caused by an outage at [vendor], which affected our ability to process new sign-ups during that window.”
- “While we can’t control our vendor’s infrastructure directly, we’re implementing a fallback so that a future outage at this specific provider won’t cause a full service interruption.”
- “We take responsibility for the impact you experienced, even though the root cause was external — here’s what we’re doing to reduce the blast radius of a similar event in the future.”
Avoiding Blame-Shifting Language
- Avoid: “This was entirely due to our vendor’s failure and outside of our control.” → Prefer: “The root cause was an outage at our infrastructure provider. We’re responsible for the resilience of our system regardless, and we’re making changes to reduce the impact of any single vendor’s downtime.”
- Avoid: “There was nothing we could have done.” → Prefer: “We didn’t have a fallback in place for this specific dependency — we’re adding one so a similar event has less impact next time.”
- Avoid silence until the vendor fixes things → Prefer: proactive updates on your own investigation and mitigation efforts, even while waiting on the vendor.
Professional Tips
- Name the vendor only if your contract and legal team allow it. Some incident communications name the third party explicitly; others keep it generic (“an infrastructure provider”) — check your company’s policy before publishing.
- Always pair “external cause” with “internal responsibility.” Customers don’t care who’s at fault technically — they care whether you’re taking ownership of the experience.
- Follow up with concrete resilience improvements, not just an apology. “We added a fallback for this dependency” is far more reassuring than “we’re sorry, it won’t happen again.”
Practice Exercise
- Write a two-sentence incident update explaining a service disruption caused by a third-party outage, without sounding like you’re avoiding responsibility.
- Rewrite this blame-shifting sentence to sound more accountable: “This was completely the vendor’s fault and there was nothing we could do.”
- Draft a short post-incident summary describing one resilience improvement you’re making after a vendor outage.