Documentation

Appearance

Build a status page ​

An organisation can create multiple status pages. Each has a public slug, title, description, public state, default-page setting, and ordered widgets.

Plan the audience ​

Choose one product, customer, region, or service boundary. Add the service endpoint, user-impact, heartbeat, incident, and explanatory markdown widgets that audience needs.

Create and preview ​

  1. Open Status pages and create a page.
  2. Set its internal name, concise public title, description, and slug.
  3. Keep it private while composing.
  4. Add and order endpoint, user-impact, heartbeat, incident, or markdown widgets.
  5. Verify each monitor label and current state.
  6. Review on the public route in a signed-out browser.
  7. Make the page public when its data boundary is safe.

One page is the organisation default. Making another page default removes that designation from the previous page.

Publish incident updates ​

Operational incidents remain internal unless explicitly published. Select the intended pages and write updates for customers:

  1. Investigating: state the observed impact and next update time.
  2. Identified: explain the affected service and mitigation without internal detail.
  3. Monitoring: state what has recovered and what is being watched.
  4. Resolved: record restoration time and any customer action.

Each update has its own publication setting. Review it before saving. Hiding an incident or page does not delete the internal response timeline.

Security and troubleshooting ​

  • Never publish secrets, hostnames, raw logs, user identities, or unreviewed root cause.
  • If a widget is absent, confirm it belongs to the same organisation and is selected in page configuration.
  • If status is stale, inspect the source monitor's last check or ping.
  • If a page is unavailable, confirm its public state and slug.
  • If customers need authenticated device workflows rather than public status, use a supported customer portal module.