What is Incident Communication?

What is incident communication?

Incident communication is telling the people affected by an outage what is happening while it is still happening: what is broken, who is affected, what you are doing and when they will hear from you next. It is separate from incident response, the technical work of detecting, containing and fixing the problem. Response restores the service. Communication looks after everyone waiting for it.

The two run in parallel and compete for the same attention, which is why communication is usually the part that slips. A team in the middle of a database failover does not feel like writing an update, and that is exactly when customers most want one.

The lifecycle of an update

Most teams use four standard labels, and readers already know what they mean:

1. Investigating: something is wrong and you are working out what.
2. Identified: you know the cause and a fix is in progress.
3. Monitoring: the fix is applied and you are watching to confirm it held.
4. Resolved: the service is behaving normally again.

Each update is added to the same incident instead of being published as a new one, so a reader can follow the whole story in order afterwards.

An example

Investigating, 14:05 UTC: "Some customers cannot log in. We are looking into it. Next update by 14:30 UTC."
Identified, 14:22 UTC: "A failing database node is causing the login errors. We are failing over to a replica. Next update by 14:45 UTC."
Monitoring, 14:41 UTC: "Logins are working again. We are watching error rates."
Resolved, 15:10 UTC: "Error rates are back to normal. We will publish a postmortem."

What makes an update useful

• Describe the impact in customer terms. "Logins are failing" beats "auth-service returning 500s".
• Say what you know and what you do not. "We do not yet know the cause" is a legitimate update and better than silence.
• Promise a next update time, not a fix time. You control when you post again, rarely when the fix lands.
• Post the first update early. A short note at ten minutes beats a detailed one at ninety.
• Avoid blame and avoid minimising. Both cost trust, in opposite directions.

Common mistakes

• Hosting the status page on the system that is down. Keep it on separate infrastructure so it survives the outage.
• Going silent once the fix is "almost done". Keep the update cadence until you reach Resolved.
• Different stories in different places. Post one text and mirror it to email, chat and social channels.
• Deleting the record afterwards. A public history of past incidents is part of what makes a status page credible.
• Relying on someone noticing. If a person has to remember to post, the post comes late. Tie the first update to your monitoring alerts.

Where updates are published

The usual home is a status page. Email subscriptions push updates to people without asking them to watch a page. Planned work follows the same pattern with an advance announcement, see scheduled maintenance. Contractual commitments around availability are covered by SLA management. A postmortem often follows a significant incident, but it serves a different audience and purpose than the updates written during it.

How LoadFocus helps

LoadFocus status pages map components to your monitors. According to the product page, turning on auto-incidents lets a failing monitor open the incident on the page by itself, and subscribers are notified when it opens and again when it closes. Incidents carry a severity (minor, major, critical) and move through investigating, identified, monitoring and resolved, and a postmortem can be published afterwards. Email subscriptions use double opt-in, the free plan includes 1 page, 10 components and 250 subscribers, and updates can also go to Slack or a webhook. Custom domains and private pages need a paid plan. For monitoring that feeds it, see API monitoring; more on running a monitoring practice in monitoring best practices for DevOps and developers.

FAQ: incident communication

How is incident communication different from incident response?

Response is the technical work of finding and fixing the problem. Communication is keeping affected people informed while that work happens. They run at the same time and usually need different people.

How often should I post updates during an incident?

Commit to a next update time in every post and keep it, even if the update only says there is no change. A regular cadence matters more than detail.

What should the first update say?

That you know about the problem, what customers are seeing, and when the next update will come. You do not need the cause yet.

Where should the status page be hosted?

Separately from the service it reports on, so it still loads when your own systems are down.

Should I publish a postmortem?

For significant incidents it helps. Describe what happened, the impact, the cause and what changes now. It is written after the event for a wider audience than the live updates.