What is Incident Communication?

What is incident communication?

Incident communication is the practice of telling the people affected by an outage what is happening, while it is still happening. It is distinct from incident response, which is the technical work of detecting, containing and fixing the problem. Response restores the service; communication manages 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 deep in a database failover is not naturally inclined to stop and write an update, and that is exactly when customers most want one.

The lifecycle of an update

Most incident communication follows a recognised sequence, and using the standard labels helps because readers already know what they mean:

1. Investigating - you know something is wrong and are working out what.
2. Identified - you know the cause; 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 rather than published as a new one, so a reader can follow the whole thing in order afterwards.

What makes an update useful

• Say what is affected 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 is better than silence.
• Commit to a next update time, not a fix time. You can control when you post again; you often cannot control when the fix lands.
• Post the first update early. An update at ten minutes saying little beats a detailed one at ninety.
• Avoid blame and avoid minimising. Both cost trust, in opposite directions.

Where it is published

The usual home is a status page, hosted separately from the service so it survives the outage. Email subscriptions push updates to people who care without asking them to watch a page, and many teams mirror the same text to chat and social channels rather than writing different versions for each.

After the incident

Once resolved, the incident record stays published. That history is part of what makes a status page credible: it shows a team that reports its failures rather than quietly deleting them. A postmortem often follows for anything significant, but it serves a different purpose and a different audience from the updates written during the event.

LoadFocus supports the full incident lifecycle with email subscribers on its status pages, including incidents raised automatically from monitor results.