LEARN. PRACTICE. GROW.Concept and mechanism
An incident update should help its recipient decide. Separate confirmed facts, suspected cause, ongoing work, and uncertainty. State the affected service or capability, how impact is changing, and when the next update will be sent. The next message time is a different commitment from a recovery forecast. If information is insufficient to forecast completion, say so clearly and explain which check may reduce uncertainty. Adapt detail to the audience: specialists need technical evidence, while business stakeholders need consequences and alternatives. Use organizational channels and approvals for external messages, avoiding unnecessary sensitive-data disclosure.
Guided application
In a fictional case, the team is investigating file delays and a stakeholder requests confirmation of recovery within ten minutes. A useful English message could say: “File delivery remains delayed. We are validating the recovery option and will provide another update at 16:30.” Add confirmed impact and communication ownership without turning the message time into a resolution promise. If the technical plan changes, update affected stakeholders. When recovery appears complete, confirm results before announcing normality and state residual effects. Vendor communication cadences are organizational examples; applicable intervals should be agreed for the actual service.
The next-update time is not an automatic recovery estimate.
Common pitfalls
Unsupported ETA; hypothesis treated as fact; excessive technical detail for business; normality announced without confirmation.
Related topics: Declaration, impact, and priority · Command, delegation, and shared state · Mitigation decisions and evidence
Maintain an explicit cadence and communicate what the evidence supports.
Reference: External Communication Guidelines · Google SRE incident guidance; PagerDuty contextual incident model; NIST SP 800-61 Rev. 3 April 2025; editorial review 2026-10-01