Downtime Communication Template

Overview

When your service goes down, silence is worse than bad news. Customers panic, internal teams guess, and executives demand answers you do not have yet. A structured communication plan lets you control the narrative, reduce support ticket volume, and rebuild trust. This template provides pre-drafted messages for internal teams, customers, and status pages at every stage of an incident.

When to Use

• For alternatives, see Incident Communication Template.

Use this resource when:

• An outage or degradation affects production services
• You need to coordinate messaging across support, marketing, engineering, and executives
• You are building an incident response runbook and need communication templates

Solution

# Downtime Communication: `<Service>`

## 1. Incident Metadata

| Field | Value |
|-------|-------|
| Incident ID | `INC-YYYY-NNNN` |
| Service | `name` |
| Start Time (UTC) | `YYYY-MM-DD HH:MM` |
| Detected By | `Monitoring / Customer report / Internal` |
| Severity | `SEV 1 (Critical) / SEV 2 (Major) / SEV 3 (Minor)` |
| Communicator | `@name` |
| Status Page URL | `https://status.example.com` |

## 2. Audience Matrix

| Audience | Channel | Timing | Owner | Template Section |
|----------|---------|--------|-------|-------------------|
| Internal — Engineering | Slack #incidents | Immediate | `@ic` | Internal technical |
| Internal — Executives | Email / Slack DM | Within 15 min | `@comms` | Executive summary |
| Internal — Support | Slack #support-alerts | Within 15 min | `@comms` | Customer-facing draft |
| External — Customers | Status page + email | Within 30 min | `@comms` | Customer notification |
| External — Enterprise | Dedicated account channel | Within 30 min | `@account-team` | Personalized update |

## 3. Message Templates

### 3.1. Initial Detection (Internal Technical)

> **Incident `INC-XXXX` — `<Service>` Degraded**
>
> - **Status**: Investigating
> - **Symptoms**: `brief description`
> - **Impact**: `affected regions / capabilities / user segments`
> - **Started**: `time`
> - **Actions**: Engineering team is investigating. Updates every 15 minutes.

### 3.2. Initial Detection (Customer-Facing)

> **Investigating — `<Service>` Issue**
>
> We are currently investigating reports of `symptom` affecting `service`. We will provide an update within 30 minutes or as soon as we have more information.
>
> **Affected**: `regions / capabilities`
> **Workaround**: `if any`

### 3.3. Update (Every 30–60 Minutes)

> **Update — `<Service>` Issue**
>
> We continue to investigate the cause of `symptom`. `Optional: We have identified the root cause as X and are applying a fix.` We expect to provide another update by `time`.
>
> **Status**: Investigating / Identified / Monitoring

### 3.4. Resolution

> **Resolved — `<Service>` Issue**
>
> `Service` is now fully operational. The issue was caused by `root cause (brief, jargon-free)`. All systems are stable and we are monitoring closely.
>
> **Duration**: `X minutes / hours`
> **Next Steps**: We will publish a post-mortem within `timeframe`.

### 3.5. Post-Mortem Notification

> **Post-Mortem — `<Service>` Incident on `Date`**
>
> We have completed our review of the incident on `date`. You can read the full post-mortem here: `link`.
>
> **Summary**: `One paragraph, no blame, no jargon.`
> **Impact**: `Duration + affected users`
> **Root Cause**: `Plain language`
> **Fixes Implemented**: `List`
> **Prevention**: `What we are doing to avoid recurrence`

## 4. Severity-Based Timing

| Severity | First Customer Update | Update Frequency | Escalation |
|----------|----------------------|------------------|------------|
| SEV 1 (Critical) | 15 minutes | Every 15 minutes | CEO notification after 1 hour |
| SEV 2 (Major) | 30 minutes | Every 30 minutes | VP notification after 2 hours |
| SEV 3 (Minor) | 1 hour | Every 1 hour | Manager notification if > 4 hours |

## 5. Approval Checklist

- [ ] Message is factual; no promises about resolution time unless confident
- [ ] No internal jargon or technical details that confuse customers
- [ ] Workaround is verified before publishing
- [ ] Legal / compliance reviewed if PII or regulatory data is involved
- [ ] Status page is updated before any other channel
- [ ] Social media / PR is aligned if external press may pick up the story

Explanation

The template separates internal communication (detailed, technical, fast) from external communication (simple, reassuring, accurate). The most common failure during incidents is promising a resolution time you cannot meet. The templates deliberately omit specific ETAs unless the fix is already deployed and validating. The audience matrix prevents support from learning about an outage from angry customers instead of from engineering.

Status Page Message Templates

=== SEV 1: Initial Detection ===

Status: Investigating
We are investigating an issue affecting [SERVICE/AFFECTED FEATURE].
Customers may experience [SYMPTOMS: e.g., login failures, slow responses].
We identified the issue at [TIME] and are actively working on a fix.
Next update in 15 minutes.

=== SEV 1: Identified ===

Status: Identified
We have identified the root cause: [PLAIN LANGUAGE DESCRIPTION].
A fix is being deployed and we expect service to be restored within [TIMEFRAME].
Next update in 15 minutes.

=== SEV 1: Monitoring ===

Status: Monitoring
A fix has been deployed and we are monitoring the service.
Preliminary indicators show improvement but we want to confirm stability.
Next update in 15 minutes.

=== SEV 1: Resolved ===

Status: Resolved
The issue has been resolved. Service is operating normally.
We will publish a post-mortem within 72 hours.
Thank you for your patience.

Internal Slack Communication Templates

=== Incident Channel: #incident-2026-07-11 ===

[11:00] @on-call: SEV1 declared — auth-service returning 500s
[11:01] @on-call: Impact: ~15% of login attempts failing, EU region
[11:02] @sre: Investigating — checking recent deployments and DB health
[11:05] @sre: Found — recent config deploy changed JWT secret rotation
[11:06] @on-call: Fix identified — rolling back config change
[11:08] @sre: Rollback deployed, monitoring error rate
[11:12] @on-call: Error rate dropping — 15% -> 3% -> 0.5%
[11:15] @on-call: Error rate at 0%. Monitoring for 10 more minutes.
[11:25] @on-call: Stable. SEV1 resolved. Post-mortem scheduled for tomorrow.

=== Support Channel: #support ===

[11:02] @on-call: SEV1 — login failures for EU users. Status page updated.
[11:03] @on-call: If customers ask: "We are aware of login issues in EU and are working on it."
[11:08] @on-call: Fix deployed, monitoring. Do not promise resolution time yet.
[11:25] @on-call: Resolved. Status page updated to green. Thank support team.

Variants

Context	Channel Mix	Tone
B2B SaaS	Status page + direct email + account manager call	Professional, accountable
Consumer app	In-app banner + Twitter / X + status page	Friendly, concise
API platform	Status page + developer Slack / Discord	Technical, transparent
Global service	Regional status pages + localized emails	Localized, time-zone aware
Security incident	Limited disclosure + direct customer notification	Careful, compliant with legal

What Works

1. Update the status page first; it is the single source of truth
2. Never say “we are back to normal” until monitoring confirms for at least 10 minutes
3. Use plain language; “database replication lag” means nothing to customers
4. Do not blame third parties publicly, even if they caused it; focus on your resolution
5. Publish a post-mortem within 72 hours for SEV 1–2 incidents; silence destroys trust

Common Mistakes

1. Waiting until the issue is “fully understood” before communicating; customers notice silence
2. Over-promising resolution time to calm stakeholders, then missing it
3. Using different wording across channels (status page says “degraded,” Twitter says “down”)
4. Forgetting to notify internal support before external customers
5. Skipping the post-mortem or making it so technical that non-engineers cannot understand it

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Production Notes

• Deploy gradually using canary or blue-green to catch regressions early.
• Configure alerts for error rate, p99 latency, and failure rate before enabling in production.
• Document the rollback in the runbook; test the procedure in staging at least once per quarter.
• Review structured logs with correlation IDs to trace requests end-to-end during incidents.

Key Takeaways

• Apply downtime communication template when you need a practical solution for your use case.
• Monitor performance after implementation; measure latency, errors, and resource usage before and after.
• Check the Troubleshooting section for common failures; most have documented root causes with fixes.
• Keep dependencies updated and run tests in CI to prevent production regressions.

Common Production Pitfalls

• Leaving required fields blank or using vague one-word answers.
• Filling the document once and never updating it after scope or decisions change.
• Storing the document where the team does not look during incidents or reviews.
• Not assigning an owner, due date, or review cadence.
• Copying boilerplate without removing sections that do not apply.
• Skipping version control, which makes rollback and accountability impossible.
• Failing to link the document to related decisions or follow-up actions.
• Avoiding quarterly reviews that would retire stale or unused sections.