Information checked: 21 July 2026.
Downtime communication should help customers act safely while giving the recovery team room to work. Clear, timed updates are more useful than vague reassurance or speculative technical detail.
In brief: Give factual scope, safe customer actions and a reliable time for the next update.
Prepare channels in advance
- An independent status page or hosting location.
- A verified social or business-profile channel where appropriate.
- Telephone or email fallback owned by the business.
- Internal staff message and customer-service script.
- Supplier and regulator contact details outside the website.
Use a simple update structure
| Element | Example purpose |
|---|---|
| Time | Show when the information was current |
| Scope | State which services are unavailable |
| Customer action | Explain a safe alternative or whether to wait |
| Data statement | Avoid claims until facts are established |
| Next update | Set a time even if resolution is not yet known |
| Contact route | Provide a channel that is actually monitored |
Avoid harmful messages
Do not blame a supplier before evidence, publish security details useful to an attacker or promise a restoration time the team cannot support. Never ask customers to send sensitive data through an improvised channel.
Acceptance check
Run a short exercise in which the website and normal business email are unavailable. Confirm that authorised staff can publish a consistent update through an independent route.
Prepare messages before an outage
Pre-approved templates reduce pressure but must contain placeholders rather than false certainty. Prepare versions for a general outage, transaction failure and suspected security incident, and assign who can publish each one.
Records to keep
- Approved message templates.
- Independent publishing credentials.
- Customer-service and staff scripts.
- Update interval and final-resolution process.
Owner test: Run an exercise with normal website and email unavailable and time how long it takes to publish a verified customer update.
Close the communication loop
After recovery, publish a final update stating which services are restored, whether customers need to repeat an action and where to report a continuing problem. Internally, compare public updates with the incident timeline and correct any inaccurate assumptions before they become part of the permanent record.
Sources and date checked
This practical guidance was checked against the following primary sources. Date checked: 21 July 2026.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.