Incident Manager
Major incident updates people will read
Ashley Jones · 15 August 2026
Incident Manager
Ashley Jones · 15 August 2026
When a major incident is running, people need clarity more than commentary. An update that gets read is short, factual, and arrives when you said it would.
Silence creates parallel chat threads, duplicate bridges, and leaders who call engineers directly. Long technical essays create the same problem in reverse: people stop reading and invent their own status.
Good communication reduces noise so the people restoring service can work. It also gives the business enough truth to make decisions about customers, workarounds, and messaging.
Use the same shape every update:
If nothing has changed, say that. “No change since the last update; next update at 14:30” is better than waiting for news that never arrives.
Keep theories off the channel. Hypothesis belongs in the technical working group, not in the stakeholder feed.
One voice owns outbound communications. Others feed facts into that person instead of posting their own versions.
Updates go out on a stated interval until service is restored or the major incident is stood down.
Business and technical audiences may need different channels, but not conflicting facts.
When service returns, the final update says what was restored, what residual risk remains, and where follow-up lives (problem, change, or review).
Waiting for a perfect root cause before saying the service is down.
Mixing apology, blame, and status in the same message. Status first. Tone can be human without becoming a novel.
Changing the update cadence without telling people. Missed expectations feel like abandonment.
Copying every technical detail into the business channel. Extra precision is not the same as usefulness.
Promise a rhythm, keep it, and stick to impact, action, and next contact time. People will read what they can trust.
We help teams put ITSM practices to work with clear ownership, practical governance, and delivery that holds up under pressure.
Contact us