A public or client-facing status page should reduce duplicated questions and give responders one approved communication channel. It is not a substitute for incident coordination, and it should not publish unverified technical guesses.
Define who the page is for
Some agencies need one public page for their own platform. Others need private or branded pages for individual clients. Define the audience, covered services and publication authority. If a site does not have a public incident-communication commitment, an internal incident record plus direct client updates may be more appropriate.
Model components around what clients recognise
Component names should describe services the reader understands, such as “Client website”, “Checkout” or “Support portal”. Internal hostnames, cluster names and provider labels can confuse clients and reveal unnecessary operational detail.
Use component states consistently. If “degraded performance” means slow responses on one incident and partial feature failure on another, readers cannot interpret the page.
Write updates that answer the next question
A useful first update states the confirmed impact, when it began, what is being done and when the next update is expected. Avoid promising a recovery time before there is evidence. Later updates should add confirmed information rather than restating that investigation continues.
| Include | Avoid |
|---|---|
| Confirmed affected service and user impact | Speculative root cause |
| Incident start or detection time with timezone | Unexplained internal error messages |
| Current response stage | Named blame before review |
| Next update time | Recovery promises without evidence |
Protect security and client confidentiality
Do not publish credentials, IP addresses, internal hostnames, exploit details, personal data or information that identifies another client's infrastructure. Security incidents may require a separate legal and communications process. The status-page owner should know when to stop and escalate.
An automated failure can create an internal incident, but it should not automatically publish a client-facing explanation unless the wording and conditions have been explicitly approved.
Close with evidence and follow-up
State what users should experience now and how that was verified. If residual work remains, say so. A later incident review can explain cause and prevention when the facts are stable and the disclosure is appropriate.
Keep incident history consistent. Quietly deleting an embarrassing outage weakens the page as a source of trust and operational learning.
A concise update template
We have confirmed that [service or journey] is [impact]. The team is [current response action]. The next update will be provided by [time], or sooner if the state changes.
Adapt the language to the client agreement and actual incident. Never use the template to fill gaps with assumptions.
Primary references
- Google SRE: Managing Incidents, including incident roles and communication structure.
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management.