Trust, Risk, and Regulated Communication
Incident Status Update
Provide time-stamped verified facts, user impact, affected scope, mitigation, workarounds, ownership, safety guidance, and the next update time.
Free editable Markdown · Incident communications teams, support leaders, and operations teams ·
Accessible HTML preview
Blank template
The downloaded file contains the same fields in editable Markdown.
Incident control
- Incident ID and title
- [Enter]
- Incident commander
- [Enter]
- Technical and communication owners
- [Enter]
- Source of approved facts
- [Reference]
- Start and detection time
- [Date/time/timezone]
- Current severity
- [Enter]
- Affected service/version
- [Enter]
- Last verified
- [Timestamp/person]
Update entry
- Public timestamp
- [Date/time/timezone]
- Current status
- [Investigating / Identified / Mitigating / Monitoring / Resolved]
- User-visible impact
- [Describe]
- Affected users/regions/features
- [Verified scope]
- Unaffected functions
- [Only if verified]
- What changed since prior update
- [Enter]
- Confirmed cause
- [Enter or Still investigating]
- Unknowns
- [List]
Action and next update
- Mitigation in progress
- [Describe]
- Safe workaround
- [Tested steps or None]
- Workaround risks/limits
- [Enter]
- Support path
- [Enter]
- User action required
- [Enter or None]
- Resolution estimate
- [Enter with confidence or None]
- Next update
- [Absolute time/timezone]
- Approver
- [Name/role]
Resolution and follow-up
- Resolution time and scope
- [Enter]
- Remaining user impact
- [Enter or None]
- Post-incident communication
- [Owner/status]
- Correction or retrospective trigger
- [Enter]
- Restoration, recovery, backlog, and monitoring are distinguished.
- Cross-channel messages and support scripts agree.
- Scheduled alerts and reminders were stopped or updated.
- Account-specific help avoids public sensitive detail.
How to use this template
- Connect to the incident source of truth and confirm owners, scope, impact, and timestamps.
- Separate verified facts, working hypotheses, unknowns, and sensitive internal details.
- Draft user impact, current mitigation, safe workaround, support, and next update time.
- Coordinate channels, publish a timestamped entry, and correct changes transparently.
- Close with restoration scope, remaining work, monitoring, user action, and follow-up owner.
Establish one verified communication source
Define incident ID, commander, technical liaison, communications owner, affected service, start time, detection time, current severity, and source of approved facts. Separate confirmed observation from hypothesis and internal diagnostic detail. An update should answer what users experience, who or which regions or features are affected, whether data or security is implicated, and what remains operational. Avoid “all users” or “no data affected” until responsible owners have verified those scopes. Coordinate public status, in-product alerts, support, social, email, and internal scripts from the same timestamped record.
Make action useful without speculation
Lead with current impact and status. Give a tested workaround only when it is safe, accessible, and does not create data loss, duplicate payment, security exposure, or extra load. State what the response team is doing at an appropriate level without publishing sensitive defensive detail. If no workaround exists, say so. Provide an absolute next-update time and timezone rather than “soon.” An estimated resolution time should include its uncertainty and owner; do not reuse an old estimate after facts change.
Preserve chronology and close responsibly
Add new updates rather than silently replacing history, while correcting materially wrong information through the incident process. Each entry needs timestamp, changed facts, impact, mitigation, workaround status, and next update. At resolution, distinguish service restoration from full recovery, queued work, monitoring, reconciliation, and any user action still needed. Link to a later post-incident report only when approved. Verify that alerts and scheduled updates stop or change state, and route remaining account-specific issues to support without asking users to expose secrets publicly.
See the fields in context
Fictional example: delayed document processing
QueueLake and every time, service, and workaround below are invented.
- Impact: Some fictional documents submitted after 14:00 UTC remain queued; editing and saved documents are unaffected, based on the imaginary incident source.
- Status: The team has identified a processing queue issue and is applying a mitigation.
- Workaround: None; repeated submission could create duplicates, so users are advised not to retry.
- Next update: 15:30 UTC, even if the status remains unchanged.
- Resolution: Later wording will distinguish restored intake from processing the existing backlog.
Frequently asked questions
What if the cause is not known?
Say the team is investigating and report verified impact, mitigation, unknowns, and next update without speculation.
Should every update include an estimate?
No. Give an estimate only when responsible owners support it; always give the next communication time.
Can old updates be edited?
Correct serious errors transparently, but preserve a clear chronology according to the incident communication process.
When is an incident resolved?
Define whether service is restored, backlog remains, data reconciliation continues, and monitoring or user action is still required.