A status page should show service information customers can understand without exposing internal infrastructure details. Publish only approved monitors and make clear what each indicator represents.
IN THIS ARTICLE
01 Create a focused page
- Confirm that status pages are available on your 360 Monitoring plan and decide whether the page is public or restricted.
- Open Pages > Add Page. Enter a clear title and approved branding. Use compact images that remain readable on phones.
- Select the website monitors and, where appropriate, server indicators to display. If selecting a dashboard overrides individual selections, review that dashboard's complete contents first.
- Arrange the components in customer-facing service groups. Replace private server names with meaningful descriptions before publishing them.
- If using a custom domain, follow the current displayed DNS instructions and confirm HTTPS works at that address. Keep the page accessible when the primary website has an outage.
- Save and inspect the result in a signed-out session. Verify the intended access restrictions, visible metrics and mobile layout.
02 Example: describe an incident in terms customers understand
A useful status update identifies the affected customer function and what is being investigated. Avoid publishing private server names, security-sensitive details or a cause that has not been confirmed.
We are investigating delayed delivery to some hosted mailboxes. Website hosting remains available. Our team is checking the affected mail route and will post another update after the next verified finding.
This is an illustrative message, not a report of a current Nabtech incident. Adapt it to verified facts and your own responsibilities before publishing.
What should a resolution message include?
State which service has recovered and how that was checked. Explain any customer action still needed, such as retrying a failed submission, only when that action is appropriate. Do not tell customers to repeat payments or orders without checking whether the original operation succeeded.
Review the public page while signed out and on a small screen. Confirm that component labels, timestamps and incident messages are understandable without access to internal dashboards. Keep the status page itself reachable through the service's supported arrangement so that an outage on your main website does not also remove the information customers need.
Common questions
Should I publish CPU, disk usage and internal server names?
Only when there is a clear customer need and approval. Service availability often communicates the relevant impact with less operational detail.
Does a green website monitor mean every customer feature works?
The indicator reports its configured check. Use clear component names and supplementary incident information when a problem affects a function the check does not exercise.
Can a password-protected page be used for internal reporting?
Where supported, configure the page password and distribute it through your approved access process. Reassess access when staff or customers change, and avoid placing secrets in the page itself.