How to write an incident update customers trust

Q: How often should I update an incident?

Choose a cadence your team can keep and publish the next update time. Atlassian suggests thirty minutes as an example, with the actual cadence depending on the situation.

Q: Is there a template I can start from?

Yes. The free status page template writes each stage of an incident update, and runs entirely in your browser.

THE SHORT ANSWER

Say what customers are experiencing, what your team knows, what it is doing next and when the next update will arrive. Update that same incident as the situation changes.

Acknowledge the customer impact first

An incident update is a service message, not a debugging transcript. Start with the task a customer cannot complete: loading reports, signing in or receiving a scheduled email. Name the affected service and say whether the issue affects everyone or a known subset.

Atlassian’s guidance recommends acknowledging an issue early and summarising its known impact. You can do that before you have a root cause. A short honest first update is more useful than a confident explanation that later turns out to be wrong.

Investigating — Reports
Some customers cannot load reports. We are investigating and will post our next update by 15:00 UTC.

Keep known facts separate from investigation

Write “we are investigating” while the cause is unknown. Move to “identified” when there is evidence for the cause and a concrete response. Do not infer data loss, a security incident or a complete recovery from one error message.

A message can be specific without exposing internal names, stack traces or customer information. “Reports are taking longer to load” describes the impact; a database exception does not tell the reader what to do.

Promise the next update, not an unverified fix time

Choose an update time your team can meet. If you cannot estimate recovery, say so and commit to the next communication instead. Atlassian gives thirty minutes as an example cadence and explicitly allows a cadence appropriate to the incident.

At that time, post even when there is no major change. State that the team is still investigating, confirm whether the impact has changed and give the next check-in. Silence leaves customers guessing.

Use each response stage for a distinct message

Keep a single incident history so readers can understand the progression. A useful writing structure is:

Investigating: known impact and the next communication time.
Identified: the confirmed cause in plain words and the action underway.
Monitoring: a change has been applied and the team is checking recovery.
Resolved: the affected task works normally again and any follow-up customers need.

Monitoring — Reports
We have applied a fix and reports are loading again. We are checking that recovery is stable. Our next update will be by 15:30 UTC.

Keep channels consistent and close the loop

Use the same impact and current stage in the status page, support replies and announcements. If one channel says “resolved” while another says “investigating”, readers cannot tell which to trust.

At resolution, state what customers can do again. If a workaround is no longer needed, say that explicitly. Link a later postmortem when it is ready rather than delaying a recovery update to write it.

Need a starting point? The free status page template writes each stage of an update for you, entirely in your browser.

Sources and further reading

Was this helpful?

Questions, answered.

Should I wait for the root cause before posting?

No. Acknowledge the known customer impact and say that you are investigating. Add the cause once it is confirmed.

How often should I update an incident?

Is there a template I can start from?

How to write release notes people actually readChangelog · 6 min read Turning feature requests into a public roadmapRoadmap · 5 min read Publishing release notes in more than one languageChangelog · 4 min read

You ship. We handle the after.

Early access opens in small groups.