Sentivel
← Guides

Incident communication: writing status updates customers trust

Last updated 23 June 2026

What to say during an outage, how often to say it, and templates for each stage of an incident. Clear, honest updates cost you far less trust than the outage itself.

During an incident, what you say is part of the product. Customers can forgive an outage. What they remember is whether you told them what was happening, whether it was honest, and whether you said when they would hear from you again. Good incident communication is mostly a habit of structure and cadence, not eloquence.

What a good update contains

  • Acknowledgement: confirm you are aware and looking into it.
  • Impact: who and what is affected, scoped as precisely as you can.
  • Action: what you are doing right now, in plain terms.
  • Next update: when they will hear from you again, even if it is just to say no change yet.

The stages of an incident

Most updates fall into four states. Investigating: you know something is wrong and are looking. Identified: you have found the cause. Monitoring: you have applied a fix and are watching it hold. Resolved: it is over, with a short note on what happened. Moving through these in order, even briefly, tells a clear story.

Templates you can reuse

  • Investigating: We are investigating reports of errors affecting [area]. Some [users/requests] may see [symptom]. We will update by [time].
  • Identified: We have identified the cause as [plain description] and are working on a fix. [Area] remains affected. Next update by [time].
  • Monitoring: A fix has been applied and [area] is recovering. We are monitoring to confirm it holds, and will resolve once stable.
  • Resolved: This is resolved as of [time]. The cause was [short, honest description]. We are sorry for the disruption and will follow up with any longer-term fixes.

Tone and honesty

Say what you can verify and nothing more. Do not promise that data is safe, do not guess at a fix time you cannot commit to, and do not make the problem sound smaller than it is. An update that overpromises and is then contradicted costs more trust than the outage. When an issue is caused by a provider you depend on, say so and attribute it to them rather than implying the fault is entirely yours.

Cadence

Pick an interval and hold it. Even a no change yet, still working update at the time you promised is reassuring, because silence reads as either you do not know or you are not saying. Let customers subscribe so the update reaches them without refreshing the page.

Post clear incident updates (and let AI draft the first version in your voice).

Start free

Frequently asked questions

What should an incident status update include?
Four things: acknowledgement that you are aware, the impact and who it affects, what you are doing about it, and when the next update will come. Keep it plain and specific.
How often should I post updates during an outage?
Pick a cadence and keep it, even when there is nothing new. A short on-time no-change update is reassuring; unexplained silence is not.
Should I say customer data is safe during an incident?
Only if you have verified it. Avoid unverifiable promises about data or fix times. Overstating safety and being contradicted later costs more trust than the incident itself.
How do I communicate an outage caused by a third party?
Attribute it to the provider and scope the impact: we are aware of an issue with a provider we rely on for [function]; some [area] may be affected until it resolves. Name the dependency without overclaiming.