Back to the Playbook
Operate & LearnOL-03
How to write user messages for downtime
Communicate known impact promptly without inventing a recovery time; maintain a clear update and all-clear sequence.
Product statusAvailable now
Input3 required inputsConfirmed affected services and user impact · Workarounds and incident updates · Initiative focus and approved Product Brain guidance
SkillsDraft incident communication · Prepare task context · Review an artifact against agreed criteriaReliability Engineer + Reliability Engineer Agent
OutcomeIncident communication: internal fact sheet, customer status drafts with timing, and the all-clear with its verification basis.Artifact: Incident communication
Owner
Reliability Engineer
Human + Agent
Participants · Agents
Sales & SupportProduct MarketingEngineerReliability Engineer Agent
Trigger
An ongoing or planned downtime situation affects users.
Required context
FilesConfirmed affected services and user impactMeetings · BetaWorkarounds and incident updatesProduct BrainInitiative focus and approved Product Brain guidance
Optional context
ConfluenceCommunication voice and templatesArchitectureService dependencies
Skills
Draft incident communicationPrepare task contextReview an artifact against agreed criteria
Suggested conversation arc
- 1Confirm impact and communication ownershipIdentify affected users, unavailable capabilities, usable alternatives and the responsible communicator. Separate known facts from unconfirmed diagnosis.Skills: Prepare task context
- 2Draft the current status messageWrite a clear acknowledgment with user impact, available workaround and next update time. Promise a resolution time only when supported by the incident owner.Skills: Draft incident communication
- 3Confirm each status revisionCheck the latest verified incident facts before approving the next message; preserve the history and do not publish without explicit authorisation.Skills: Review an artifact against agreed criteria
- 4Verify recovery evidenceObtain confirmation from operations that affected behaviour has recovered, including residual limitations; if recovery is partial keep the incident open.
- 5Prepare all-clear and follow-upDraft the all-clear using verified recovery and state remaining limitations. Prepare a later factual follow-up if needed, keeping the incident postmortem distinct.Skills: Draft incident communication
Output
Incident communication: internal fact sheet, customer status drafts with timing, and the all-clear with its verification basis.
Artifacts
Creates: Incident communication
What good looks like
- Copy reflects the current supported incident facts.
- An unknown ETA is never replaced by an invented promise.
- No all-clear without recovery evidence.
Quality gate
The incident owner approves every message; publishing is a separate authorised action.
Destination
Status pageSlack
Usually next
People and agents work from the same Product Brain. The owner stays accountable. Assigned agents prepare and check. A named person approves at the gate.
Choose the path that matches your role.
Set the Product AI direction with us, or test the shared Product Brain on real work with Jira and code.