Incident communication should explain the affected capability, known scope, current mitigation and next update expectation. Separate observed facts from investigation hypotheses. A status page being green does not establish that every customer workflow is healthy, and restoring infrastructure does not automatically resolve queued business work.
Let’s plan your incident communication.
Bring your workflow, constraints and open questions. We’ll help you define the requirements and work through a practical next step.
Define the communication owner
Identify who approves updates, which audiences receive them and how support obtains the current explanation. Keep technical investigation and customer communication coordinated without requiring every investigator to publish independently.
For a hypothetical reporting outage, users need to know whether reports are delayed, incomplete or unavailable. A generic Some users may experience issues can leave them making decisions with stale data.
Use an update evidence worksheet
| Update element | What to state | Claim to avoid |
|---|---|---|
| Affected service | Specific capability under investigation | Entire platform scope without evidence |
| Impact | Observed user or workflow effect | Invented affected-user percentage |
| Timing | Known start or detection time | Precise start guessed from the first complaint |
| Mitigation | Action actually applied | Planned fix described as completed |
| Recovery | What checks passed and work remains | Everything fixed before reconciliation |
| Follow-up | Next update or review process | Unsupported guaranteed repair time |
Use the organisation's approved incident and disclosure procedures. Security incidents may require additional qualified legal and security review beyond a routine availability update.
Keep recovery messages specific
Distinguish service restored, backlog processing and business reconciliation. If users need to retry an action, explain which actions are safe to repeat and which need verification first.
Do not expose customer data, credentials or exploitable implementation details in public updates. Provide additional controlled context to authorised support staff where necessary.
Exercise communications during drills
Simulate a failure with delayed jobs and uncertain outcomes. Verify the responsible person can publish accurate updates and that support uses consistent information.
After recovery, review whether messages helped users choose a safe next step. Faster updates are useful only when they remain truthful and understandable.
Incident communication questions
Should we publish the suspected root cause immediately?
Identify uncertainty clearly and follow the approved process. An early hypothesis can change during investigation.
Is the incident closed when the error rate returns to normal?
Check the affected business outcomes and backlog too. Normal request metrics can coexist with unresolved records.
Use integration monitoring runbooks, and discuss operational readiness with Drema's cloud and DevOps team.