A form stops sending messages, payment remains pending or the website does not open. During an incident, customers need practical information even while the team investigates the cause. Silence may encourage repeated orders, while an optimistic promise can create further problems. Prepare a simple way to communicate facts, uncertainty and the next step before an incident happens.
Describe impact before assumptions
Explain which function is affected and what users may notice. “Some form submissions are not being confirmed” is more useful than “technical difficulties”. State the known period and whether other functions remain available. Do not blame a supplier without evidence or describe an ordinary error as an attack merely because its cause is unknown. Symptoms and causes are different kinds of information.
Give customers a safe action
If repeating a payment could cause confusion, explain that its status needs checking before another attempt. When a form is unavailable, provide an alternative channel that actually works. Do not request passwords, complete card details or personal documents in public comments. Avoid improvised alternatives the team cannot track. The message should reduce impact, not merely reduce the number of questions.
Decide who updates the information
One person coordinates messages while the technical owner validates facts. Keep a shared timeline of observations and interventions. If the main website is affected, the information channel should not depend on the same failing component. Do not invent a status page or emergency number during an incident without checking its availability and assigning responsibility.
Promise an update rather than a guessed recovery time
You can state when you will provide more information even if you do not know when repair will finish. Keep that commitment and explain what changed or remains under investigation. Use clear times and time zones for international audiences. Avoid “everything will be back in five minutes” without a reliable estimate. A short, accurate message is more useful than speculative technical detail.
Close the incident after verification
One successful page load does not prove that every operation has recovered. Check the affected journeys and any requests left pending. Explain recovery and what people should do if they remain affected. If personal data may be involved, engage those responsible for assessing applicable obligations. Afterwards, record the confirmed cause and concrete improvements without promising that problems can never recur.
Sources and further reading
A CloudCity editorial guide informed by the documentation below. Check the official source for rules and procedures that may change.
