How to Communicate Vendor Outages to Your Customers

Your payment processor just went down. Your checkout flow is broken. Customers are trying to buy things and getting error messages. You know the problem is on Stripe's end, not yours. But your customers do not know that, and they do not care. All they know is that your product is not working.

How you communicate during a vendor outage defines how your customers perceive you. Get it right, and you build trust. Get it wrong, or stay silent, and you lose it.

This guide covers when to notify customers, what to say, which channels to use, and provides ready-to-use templates for every phase of a vendor outage.

When to Notify Customers

Not every vendor outage requires customer communication. The decision depends on two factors: customer impact and expected duration.

Notify Immediately When

Customers cannot complete a core action. If checkout, login, or any primary workflow is broken, communicate immediately. Do not wait for the vendor to publish a status update. Do not wait to fully understand the root cause. Your customers are already experiencing the problem.

Data integrity may be affected. If there is any possibility that customer data has been lost, duplicated, or corrupted, communicate immediately. Even if you are not yet sure of the scope.

The outage is visible. If your app is showing error messages, loading indefinitely, or behaving obviously wrong, your customers already know something is up. Silence at this point feels like you are either unaware or hiding something.

Consider Waiting When

The impact is minor and the fix is imminent. If a non-critical feature is degraded and the vendor's status page indicates a resolution is in progress, a brief monitoring period makes sense. If it resolves within 10 to 15 minutes, you may not need to communicate at all.

Only internal operations are affected. If the outage hits your CI/CD pipeline or internal tools but has zero customer-facing impact, there is no reason to notify customers. Focus on internal communication instead.

The 15-Minute Rule

A good default: if a customer-facing issue persists for more than 15 minutes with no sign of imminent resolution, send the first notification. Waiting longer than that creates a perception gap where customers are experiencing problems, talking about them to each other, and getting no information from you.

What to Say (and What Not to Say)

Outage communication is about clarity, honesty, and empathy. It is not about technical precision or legal protection.

What to Include

Acknowledge the problem. State clearly what is not working. Use language your customers understand. "Some users are unable to complete purchases" is better than "our payment gateway is returning 503 errors."

State what you know. Share whatever you know, even if it is incomplete. "We have identified the cause and our provider is working on a fix" is more helpful than saying nothing until you have every detail.

Set expectations. Give customers a timeline if you can. If you cannot, say so: "We do not have an estimated resolution time yet, but we are monitoring closely and will update you within 30 minutes."

Provide a workaround if one exists. If customers can accomplish what they need through an alternative path, tell them. "You can still place orders by contacting our support team at support@example.com" turns a dead end into a detour.

What Not to Say

Do not blame your vendor publicly. It is tempting to say "Stripe is down and there is nothing we can do." But your customers chose your product, not Stripe's. Shifting blame makes you look helpless and unprofessional. You can mention that the issue is with a third-party provider without naming them or throwing them under the bus.

Do not over-promise on timelines. If you say "this will be resolved within the hour" and it takes three hours, you have made the situation worse. Under-promise and over-deliver.

Do not use jargon. Skip the technical details in customer-facing communication. Save the root cause analysis for your internal post-mortem.

Do not apologize excessively. One clear apology is appropriate. Repeating "we are so sorry" in every update dilutes the message and starts to feel performative.

Communication Channels

Different channels serve different purposes during an outage. Use the right one for the right audience.

Status Page

If you have a public status page (and you should), this is your primary communication hub. Update it first, then link to it from other channels. A status page provides a persistent, referenceable location where anyone can check the current state of affairs.

Status pages work well because they do not require customers to be watching a specific channel at the right time. Anyone who comes looking for information can find it. Tools like Statuspage by Atlassian, Instatus, or a simple custom page all work.

Email

Email is the right channel for outages that affect a large portion of your customer base and are expected to last more than 30 minutes. Email reaches customers who may not be actively using your product right now but will be affected when they try.

Keep outage emails short. Subject line should state the issue clearly: "Service disruption affecting checkout" is better than "Important update about our platform." Include the current status, expected timeline, and a link to your status page for ongoing updates.

In-App Notifications

For customers who are actively using your product when the outage hits, an in-app banner or notification is the fastest way to communicate. It reaches the exact people who are affected, at the exact moment they are affected.

A simple banner at the top of your app saying "We are experiencing issues with payment processing. Our team is working on a fix." prevents customers from repeatedly retrying and getting frustrated by silent failures.

Social Media

Monitor your social media mentions during outages. Customers often go to Twitter/X or other platforms to ask "is [your product] down?" before checking anywhere else. Posting a brief acknowledgment on your social accounts lets you control the narrative rather than letting frustrated customers define it.

Keep social posts factual and brief. Link to your status page for details. Do not get into back-and-forth troubleshooting in replies.

Direct Support Channels

Your support team needs to be informed before customers start contacting them. Send an internal alert with talking points so every support agent can give consistent, accurate information. Nothing erodes trust faster than getting different answers from different support agents during an outage.

Templates

Here are ready-to-use templates for each phase of a vendor outage. Adapt the language to fit your brand's voice.

Initial Notification

Subject: Service disruption affecting [feature/workflow]

We are currently experiencing an issue affecting [describe what is not working in plain language]. Some users may be unable to [specific action, e.g., "complete purchases" or "log in to their accounts"].

Our team identified the issue at [time] and we are actively working with our infrastructure provider to resolve it. We do not have an estimated resolution time yet, but we will provide an update within [30 minutes / 1 hour].

[If workaround exists:] In the meantime, you can [describe workaround].

We apologize for the inconvenience and will keep you posted as we learn more.

For real-time updates, visit our status page: [link]

Progress Update

Subject: Update on [feature/workflow] disruption

Updating you on the service disruption we reported at [time]. Here is what we know:

The issue is still being worked on by our infrastructure provider. The root cause has been identified and a fix is in progress. We expect the issue to be resolved by [estimated time, if known].

[Describe any changes in scope: "The issue is now also affecting [feature]" or "The issue appears limited to [specific region/segment]."]

We will send another update in [timeframe] or sooner if the situation changes.

Resolution Notification

Subject: Resolved: [feature/workflow] is back to normal

The service disruption affecting [feature/workflow] has been resolved as of [time]. All systems are operating normally.

Here is a brief summary of what happened:

• The issue began at [time] and affected [describe scope].
• The root cause was a disruption with one of our third-party infrastructure providers.
• Service was fully restored at [time], for a total disruption of approximately [duration].

We understand this caused inconvenience and we are reviewing our processes to reduce the likelihood and impact of similar issues in the future.

If you are still experiencing any problems, please contact our support team at [email/link].

Thank you for your patience.

Post-Incident Communication

After the outage is resolved, you have one more communication opportunity that most companies miss: the follow-up.

Within 24 to 48 hours of resolution, send a brief post-incident summary to affected customers. This does not need to be a full technical post-mortem. It should cover:

What happened. A plain-language explanation of the incident. "One of our third-party service providers experienced an outage that affected our payment processing system."

What the impact was. Be specific about duration and scope. "The issue lasted approximately 2 hours and 15 minutes and affected roughly 30% of checkout attempts during that window."

What you are doing about it. Describe concrete steps you are taking to prevent or mitigate similar incidents. "We are adding a backup payment processor that will automatically activate if our primary provider experiences an outage." Customers do not expect perfection. They expect you to learn and improve.

What happened to their data/transactions. If applicable, explain whether any transactions failed, were duplicated, or need attention. Proactively resolve any billing issues rather than waiting for customers to discover them.

This follow-up communication is where you turn a negative experience into a trust-building moment. Companies that communicate transparently after incidents consistently score higher in customer satisfaction surveys, according to Atlassian's guide to incident communication.

Preparing Before the Outage

The best outage communication happens when you prepare before anything goes wrong.

Draft your templates now. Do not write your first outage email while the outage is happening. Have templates ready, reviewed, and approved.

Set up monitoring and alerting. You cannot communicate about an outage you do not know about. Use vendor monitoring to detect outages as soon as they happen. Our vendor monitoring guide covers setup in detail.

Define your communication thresholds. Decide in advance which types of outages trigger which channels. Document this in your vendor outage response playbook so decisions are pre-made, not improvised under pressure.

Identify your communicators. Decide who writes and approves outage communications. During an incident, the people fixing the problem should not also be the people writing customer emails. Separate the roles.

Test your channels. Make sure your status page works, your email lists are up to date, and your in-app notification system can be triggered quickly. You do not want to discover a broken notification system during a real outage.

The Bottom Line

Vendor outages are going to happen. You cannot prevent them. But you can control how your customers experience them. Fast, honest, empathetic communication turns a frustrating situation into evidence that your company is competent and trustworthy.

The formula is simple: detect the outage quickly, acknowledge it immediately, update regularly, resolve transparently, and follow up with what you learned. Every step depends on the one before it, and the first step, detection, depends on having monitoring in place before the outage starts. Pair vendor monitoring with uptime monitoring for your own services and DNS monitoring to ensure the full picture is covered.

References

• Atlassian - Incident Communication Best Practices - Comprehensive guide to incident communication frameworks and templates.
• Statuspage by Atlassian - Industry-standard tool for public status page communication during incidents.