Incident Communication Templates for Third-Party Downtime

When a vendor your business depends on goes down, you have two problems. The first is the outage itself. The second is telling people about it. Most teams spend all their energy on the first problem and improvise the second. The result is a flurry of vague Slack messages, a delayed customer email drafted under pressure, and a status page update that says nothing useful.

Pre-written templates fix this. When you have the words ready before the incident happens, communication becomes a five-minute task instead of a thirty-minute scramble. You fill in the specifics, send it, and get back to managing the actual problem.

This guide provides copy-pasteable templates for every phase of a third-party outage: initial notification, ongoing updates, and resolution. We cover email, Slack, status page, and social media formats, along with guidance on when to communicate, what not to say, and how to write a post-incident summary.

When to Communicate

Not every vendor hiccup requires a message to your entire customer base. But waiting too long is almost always worse than communicating too early. The decision comes down to three questions.

Is the customer experience affected? If customers can still do everything they need to do, there is nothing to communicate externally. Handle it internally and move on.

Has it lasted more than 15 minutes? Brief blips resolve on their own. If a customer-facing issue persists beyond 15 minutes with no sign of resolution, it is time to send the first notification.

Are customers already noticing? If your support inbox is filling up or people are posting about it on social media, you are already behind. Communicate immediately.

For a deeper framework on communication timing and channel selection, see our outage communication guide. The templates below are designed to plug into the vendor outage response playbook at the communication steps.

Template Type 1: Initial Notification

The first message acknowledges the problem, states what you know, and sets expectations. Speed matters more than completeness here. You do not need to understand the root cause before sending the first notification.

Email: Initial Notification

Subject: Service disruption affecting [feature name]

Hi [Customer / Team],

We are currently experiencing an issue with [describe affected functionality in plain language, e.g., "payment processing" or "file uploads"]. Some users may be unable to [specific action].

Our team identified the issue at [time] and we are actively working to resolve it. The problem has been traced to one of our third-party service providers, and we are in contact with them.

We do not have an estimated resolution time yet. We will send an update within [30 minutes / 1 hour] with more information.

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

We apologize for the disruption.

[Your name or team name]

Slack: Initial Notification

Use this for internal team channels or a dedicated incidents channel.

:rotating_light: Vendor Outage Alert

What: [Vendor Name] is experiencing an outage
Impact: [Describe what is broken for your users/team]
Severity: [Critical / High / Medium]
Started: [Time, with timezone]
Status: Monitoring - vendor has acknowledged the issue

Action needed:
- [Team/Person] is leading the response
- Workaround: [describe, or "none available"]
- Next update in [15/30] minutes

Vendor status page: [link]

Status Page: Initial Notification

Keep status page updates short and factual. Customers scanning your status page want the essentials, not a narrative.

Investigating - We are investigating reports of issues
with [component name]. Some users may experience
[describe symptom]. We have identified the cause as
an issue with a third-party provider and are working
toward resolution. Next update in 30 minutes.

Social Media: Initial Notification

Social posts need to be even shorter. Acknowledge, state the scope, and point people to your status page.

We're aware of issues affecting [feature]. Our team is
on it and we're working with our service provider to
resolve this as quickly as possible. Updates:
[status page link]

Template Type 2: Ongoing Updates

During an active incident, silence is your enemy. Even if nothing has changed, say that nothing has changed. Regular updates show customers that you are actively working the problem, not ignoring it.

Email: Progress Update

Subject: Update on [feature name] disruption

Updating you on the service issue we reported at [time].

Current status: The issue is still being worked on. Our third-party provider has identified the root cause and a fix is in progress.

What has changed: [Describe any change in scope, e.g., "The issue is now also affecting email notifications" or "The issue appears limited to users in the EU region."]

Expected resolution: [Estimated time if the vendor has provided one, or "We do not have a firm estimate yet but will update you as soon as we do."]

[If new workaround is available:] We have identified a workaround: [describe].

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

[Your name or team name]

Slack: Progress Update

:arrows_counterclockwise: Outage Update - [Vendor Name]

Status: Still down - vendor reports fix in progress
Duration: [X] minutes so far
Changes: [Any new info or scope change]
ETA: [Vendor's estimate, or "No ETA from vendor yet"]

Next update in [15/30] minutes.

Status Page: Progress Update

Update - Our provider has identified the root cause
and is implementing a fix. We are continuing to
monitor. [Component] remains degraded. Next update
in 30 minutes or sooner if status changes.

Template Type 3: Resolution

The resolution message confirms the fix, summarizes what happened, and tells people what to do if they are still experiencing issues.

Email: Resolution Notification

Subject: Resolved: [feature name] is back to normal

The service disruption affecting [feature name] has been resolved as of [time].

Here is a summary:

• The issue began at [start time] and was resolved at [end time], lasting approximately [duration].
• The cause was a disruption with one of our third-party service providers that affected [describe scope].
• During the outage, [describe impact, e.g., "approximately X% of payment attempts failed" or "file uploads were unavailable"].

All systems are now operating normally. If you attempted [action] during the outage and it failed, [explain whether they need to retry, whether it was queued, etc.].

If you are still experiencing any issues, please contact us at [support email/link].

We are reviewing our processes to reduce the impact of similar incidents in the future. Thank you for your patience.

[Your name or team name]

Slack: Resolution

:white_check_mark: Resolved - [Vendor Name] Outage

Duration: [start time] to [end time] ([total duration])
Root cause: [Brief description from vendor]
Impact to us: [What was affected for your team/customers]
Follow-up: [Any action items, e.g., "Retry failed jobs" or "No action needed"]

Post-incident review scheduled for [date/time].

Status Page: Resolution

Resolved - The issue affecting [component] has been
resolved. All systems are operating normally.
The disruption lasted approximately [duration] and
was caused by an issue with a third-party provider.
We apologize for the inconvenience.

Social Media: Resolution

The issues affecting [feature] have been resolved.
Everything is back to normal. We apologize for
the disruption and appreciate your patience.
If you're still experiencing problems, reach out
to our support team: [link]

What NOT to Say

Templates keep you consistent. But knowing what to avoid is just as important as knowing what to include.

Do not name your vendor publicly. Saying "Stripe is down" in a customer-facing message looks like blame-shifting. Say "one of our service providers" or "a third-party provider." Your customers chose your product, and they hold you responsible for the experience regardless of whose infrastructure failed.

Do not speculate on timelines you cannot control. If the vendor has not given an ETA, do not invent one. "We expect this to be resolved within the hour" sounds reassuring until hour two, when it becomes a broken promise. Stick to "we will update you in [timeframe]."

Do not over-explain the technical details. Customers do not need to know about DNS propagation delays or database failover procedures. Save the technical analysis for your internal post-incident review.

Do not minimize the impact. If checkout is completely broken, do not call it "intermittent issues." Customers who just watched their purchase fail know the difference between your language and their experience.

Do not apologize repeatedly. One sincere apology per message is appropriate. Stacking apologies in every sentence dilutes the message and starts to sound performative.

Post-Incident Summary Template

Within 24 to 48 hours of resolution, send a post-incident summary to affected customers. This is optional for minor incidents but expected for anything that significantly affected the customer experience. According to Atlassian's incident communication framework, post-incident transparency is one of the strongest drivers of customer trust after a failure.

Subject: Post-incident summary: [feature name] disruption on [date]

On [date], [your product] experienced a service disruption affecting [feature name] that lasted approximately [duration]. We want to share what happened, what the impact was, and what we are doing about it.

What happened

At [time], one of our third-party service providers experienced an outage that affected our [feature/system]. This caused [describe customer-facing symptoms].

Timeline

• [Time] - Issue began
• [Time] - Our monitoring detected the problem and alerted the team
• [Time] - We confirmed the issue was with a third-party provider
• [Time] - First customer notification sent
• [Time] - Vendor implemented a fix
• [Time] - We verified full service restoration

Impact

During the [duration] window, [describe specific impact: number of affected users, failed transactions, etc.]. [If applicable: All failed transactions have been reprocessed / credits have been applied / no data was lost.]

What we are doing

• [Specific action, e.g., "Adding a backup provider for payment processing"]
• [Specific action, e.g., "Implementing automatic failover for this service"]
• [Specific action, e.g., "Improving our monitoring to detect this type of failure faster"]

We understand this caused inconvenience and we take reliability seriously. If you have questions, contact us at [support email/link].

[Your name or team name]

Internal Communication: Do Not Forget Your Team

Most of this guide focuses on customer communication, but your internal team needs templates too. Support agents fielding customer calls need talking points. Engineers need to know what the business impact is. Leadership needs a summary they can forward without editing.

Internal Talking Points for Support Teams

INTERNAL - Support Talking Points
Issue: [Vendor] outage affecting [feature]
Started: [time]
Current status: [Investigating / Fix in progress / Resolved]

What to tell customers:
- "We are aware of the issue and our team is working on it."
- "The problem is with one of our service providers, and
  we expect it to be resolved [timeframe if known]."
- "I can [offer workaround / take your details and follow
  up when it is resolved]."

What NOT to say:
- Do not name the vendor
- Do not promise a specific resolution time unless
  confirmed by engineering
- Do not say "there is nothing we can do"

Escalation: If a customer reports data loss or billing
issues related to this outage, escalate to [person/team].

Setting Up Your Template Library

Having templates is only useful if your team can find them in the moment. Store your templates somewhere accessible that does not depend on the service that might be down.

Keep a shared document or wiki page with all templates organized by phase (initial, update, resolution) and channel (email, Slack, status page, social). Make sure at least two people on your team know where the templates live and how to use them.

Review and update templates quarterly as part of your vendor monitoring practice. Update contact information, refine language based on past incidents, and add templates for new communication channels your business has adopted.

Understanding the cost of downtime helps you calibrate the urgency and tone of your templates. A five-minute blip on an analytics tool warrants a different communication posture than a two-hour outage on your payment processor.

References

• Atlassian - Incident Communication Best Practices - Framework for incident communication with research on how transparency affects customer trust.

Beyond vendor monitoring, pair your alerting setup with uptime monitoring for your own services and DNS monitoring to distinguish between vendor outages and your own infrastructure failures.