## TL;DR
Scheduled downtime comms run in three phases: before (notice with impact and timing), during (status page updates on schedule, even if "still on track"), and after (all-clear plus what changed). Assign one comms owner for all three. The most common failure is silence during the window: customers assume the worst when the updates stop.

## The query

```text
scheduled downtime: support communication template
```

## Use this when

- Planning downtime communications
- Downtime comms are chaotic or inconsistent
- Building the maintenance runbook
- Support gets blindsided by planned work

## Not for

- Unplanned outages (different playbook)
- The maintenance engineering work itself
- Marketing communications
- Minor no-impact changes

## Steps

### 1. Assign the comms owner before anything else

One person owns all customer communication for the downtime: the notices, the during-window updates, the all-clear. Not the engineer doing the work. Split attention produces silence.

Expected output: a named comms owner.

### 2. Send the pre-notice on schedule

One week ahead by email, reminder the day before, banner in-app. Impact, times with timezone, what to do. Use the maintenance notice template. Support gets the macros at the same time customers get the notice.

Expected output: notices sent, macros ready.

### 3. Update during the window on a cadence

Every 30 minutes on the status page, even if the update is "on track, halfway done." Silence during downtime is interpreted as trouble. The comms owner posts; engineering feeds them one line per cadence.

Expected output: regular updates through the window.

### 4. Send the all-clear and the summary

"Maintenance complete at [time]. [Service] is fully available. We [upgraded X], which means [customer benefit]." If it overran, say so and say why in one sentence. Then remove the banners.

Expected output: all-clear sent, banners removed.

### 5. Arm support for the aftermath

Macros for "was my data affected," "it is still slow," and "I missed the notice." A short debrief: what confused customers this time. Feed it into the next downtime's notice.

Expected output: aftermath macros and a debrief note.

## Template: the three phases

```text
BEFORE (T-7 days email, T-1 day reminder, in-app banner):
[Maintenance notice: impact, times with zone, what to do, why.]

DURING (status page, every 30 min):
[Time]: [on track / phase] - [one line]. Next update [time].
[Time]: complete / extended to [time] because [one line].

AFTER (email + status page):
All clear at [time]: [service] fully available.
What changed: [customer benefit in one line].
[If overran: it ran [X] over because [one line]. Sorry about that.]
Questions: [support channel]. Macros live for: data concerns, slowness, missed notice.
```

## Variant phrasings

### downtime communication plan

Steps 1 through 4. Owner, notice, cadence, all-clear.

### planned outage customer messaging

Full sequence. Step 5 closes the loop.

### maintenance window status updates

Step 3. The cadence is the whole answer.

## Why it works

Planned downtime is a trust transaction: you borrow the customer's patience and repay it with punctuality and communication. The cadence during the window is what separates "professional maintenance" from "are they down." The all-clear with the benefit stated turns an annoyance into evidence of investment.

## Edge cases

- The downtime gets canceled: announce the cancellation as loudly as the downtime. Silence breeds "did it happen."
- It finishes early: send the all-clear early. Do not let the window run on the clock while service is up.
- It overruns badly: update more often, not less. Frequency is reassurance.
- Support was not told: that is a process failure. The pre-notice checklist must include "support briefed."

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_caW-5SkxU94tHWfu6IY9tA