When a major cloud provider or SaaS vendor goes down, your clients hear about it from the news, a peer, or their own users, and then they wonder whether you noticed and whether they are affected. The worst outcome is silence. This play is about getting ahead of that moment: detecting third-party outages early and communicating impact-specific, accurate information that provides peace of mind without manufacturing alarm. It is distinct from Incident Response and Severity Classification, which handles failures in systems you own and operate. Here the failure is upstream, in someone else's infrastructure, and your job is awareness plus communication rather than remediation.

When to use this play#

Use it for outages in the third-party services your clients' applications depend on, where critical functionality becomes unavailable or degraded and you do not control the fix. The trigger is a status change in a dependency, not a code deploy of yours.

Start by building a Tier 1 dependency list: the external services whose failure would meaningfully affect client applications. Typical members include major cloud platforms, app stores, mobile platform vendors, CDN and DNS providers, email and SMS delivery services, analytics and monitoring/observability tools, CRM and marketing platforms, payment and identity providers, and AI/LLM APIs. The point is not the exact list, it is having one and keeping it current as client stacks evolve.

How to run it#

1. Monitor every Tier 1 dependency automatically. A status-aggregation service that watches vendor status pages is the cleanest primary source. Back it with the vendors' own status notifications and, for the largest events, general news monitoring. Engineering owns the monitoring configuration so coverage matches the dependency list.

2. Route detections to a single internal channel instantly. A status change should post automatically to a dedicated internal channel that reaches engineers, account and delivery leads, and leadership. Name an owner (for example, the engineering lead) responsible for confirming company-wide visibility if the automation ever fails. Internal awareness comes before any client message.

3. Triage with a fixed set of questions. The moment you learn of an outage, answer:

• Which service is affected?
• When was it detected?
• What is the known or potential client impact?
• What is the current status and estimated resolution, if any?
• What needs to be communicated, and to which clients?
• Who owns each client conversation?

4. Decide who to contact using clear triggers. Communicate to a client when an outage directly affects their specific infrastructure, when a large-scale platform outage is making news and could plausibly worry them even if their impact is indirect, or when public reporting could reasonably cause concern. Stay silent when the outage affects services the client does not use, when impact is negligible to their operations, or when the issue resolves before any client impact occurs. Silence is a deliberate choice here, not neglect.

5. Segment by dependency, not by blast email. Map affected services to the clients who use them, plus any with plausible indirect exposure, and target only those. A vendor-wide broadcast erodes trust as fast as silence does.

6. Hit your response SLA. During business hours, the owning lead sends the first client message within a defined window of detection (a two-hour target works well). Speed matters more than completeness on the first message; you can follow up as facts firm up.

7. Use a consistent message structure. Keep a small set of reusable templates so people are not drafting under pressure. The structure that covers most situations:

• Direct-impact notice. State the affected service, the specific impact on their site or product, that you are actively monitoring, and that no action is required from them. Promise a follow-up on resolution.
• Proactive "peace of mind" notice. For newsworthy outages, acknowledge they may be seeing reports, confirm their systems are operational or unaffected, and say you are watching closely.
• Resolution / all-clear. Close the loop, confirm normal operation, and offer a one-line cause summary if useful.
• Impact-inquiry response. When a client asks for specifics, give honest, concise duration and impact, and address data integrity directly. The reassurance that no data or submissions were lost is often what they actually need.

8. Follow up as status changes. Send updates when the situation materially changes and a final all-clear when the vendor confirms resolution. Each open notification should eventually get a close.

Common traps#

• No maintained dependency list. Without it, monitoring has gaps and you find out from the client. Revisit it as client stacks change.
• Over-communicating. Messaging every client about every blip trains them to ignore you and creates needless anxiety. The "do not communicate" triggers are as important as the "do."
• Speculating on impact or cause. Say what you know, say you are monitoring, and follow up. Guessing wrong is worse than saying "we are confirming details."
• Skipping internal alignment. If account leads send conflicting messages or none, the client sees disorganization. One internal channel, clear ownership per client.
• Forgetting the all-clear. An unclosed outage notification leaves the client assuming things may still be broken.
• Hedging on data integrity. When clients ask, they are usually worried about lost data. Be direct and specific about what was and was not affected.

Signals it's working#

• Your team consistently knows about Tier 1 outages before clients ask, often before mainstream coverage.
• First client communications reliably land inside your response SLA during business hours.
• Clients reply with thanks rather than alarm, and the messages reduce inbound "are we down?" questions instead of generating them.
• Only affected and plausibly-affected clients hear from you, and every notification eventually gets a resolution follow-up.
• After a big public outage, your clients feel informed and calm rather than scrambling, which is the entire point.