> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Incident Comms Cadence

> During a major incident, updates go out on a clock — internal and client — even when the update is "no change." Draft each update from ticket evidence, track the next-due time, and never let the cadence silently lapse.

<Info>
  **Category:** Change & Problem Management · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/change-and-problem-management/incident-comms-cadence/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Service & Ops Manager](/start-here/roles/service-ops-manager)

**Outcome:** Faster Resolution & Response

**When to use:** a major incident was declared and updates need drafting on schedule / "draft the next client update / what do we tell them at the top of the hour?" / the comms lead wants a check on whether we're current and when the next update is due / post-incident reconstruction of what was communicated when.

**Run it:** on one incident.

## Prompt

```
Run the update clock set at declaration: who gets updated, at what interval, saying what.
Treat a missed update as an incident-response failure in its own right — in a major, silence
is read as bad news.

1. Load the cadence from the master incident ticket: intervals (default internal 30 min /
   client 60 min; a client's contractual terms override when stricter), audiences, and the
   comms lead who approves sends.

2. WHO SAYS WHAT — two different artifacts, never one message dual-purposed:
   - Internal update (plain-text note on the master ticket, for the response team):
     technical state, workstream progress, hypotheses including uncertain ones, resource
     needs. Candid.
   - Client update (drafted for the comms lead): impact in the client's terms, what's
     being done stated plainly, next update time, and an ETA ONLY if the IC has committed
     one. Follows the outage-notification framing; anything security-flavored follows the
     defensive-writing standard — no "breach," no cause speculation.

3. Draft each update strictly from ticket evidence since the last update. The no-progress
   update is legitimate and has a fixed shape: "still working, here's what we've ruled out,
   next update at <time>." Never invent progress to make an update feel worthwhile.

4. Every client update states when the next one comes — and that promise becomes the new
   deadline. An update that goes out late is still sent, with the honest timestamp; the
   lapse is noted internally, not papered over.

5. Route client-facing drafts to the comms lead for approval and send; confirm the audience
   list against the client's documented incident contacts — updates to
   the wrong contact list are a common majors failure. Record each sent update (time,
   audience, gist) in a note so the comms trail is reconstructable.

6. On stand-down: draft the closure notice (service restored, monitoring continues, RFO to
   follow — see rfo-letter) and record cadence end.

CADENCE CHECK: read the master ticket's comms notes, compute last-sent vs. interval for
each audience, and report: current / due in N minutes / OVERDUE by N minutes, with the next
drafts ready.

Guardrails: the agent drafts and tracks; the comms lead (a human) approves and sends
anything client-facing — no unattended client sends during a major. Never state a cause to
clients before the IC confirms it — early cause statements are almost always wrong and live
forever in inboxes. Never promise an ETA the IC hasn't committed to; "next update at <time>"
is the only promise the drafter may originate. One clock, one owner: if the comms-lead role
is unassigned or ambiguous, flag it to the IC immediately. Internal candor, external
discipline: hypotheses stay internal until confirmed.
```


## Related topics

- [Network Outage Triage](/skill-library/devices-and-infrastructure/network-outage-triage.md)
- [Incident Commander Brief](/skill-library/change-and-problem-management/incident-commander-brief.md)
- [Major Incident Declaration](/skill-library/change-and-problem-management/major-incident-declaration.md)