← Back to help centre

Public status pages

Designing useful status-page components

Choose clear public status-page components that communicate customer impact without exposing internal monitoring detail.

A status page works best when its components match the services customers understand. Use WebCheck components to communicate impact, not to publish every internal target or diagnostic detail.

Choose customer-facing names

  • Website for the primary public service.
  • API for a public API customers depend on.
  • Checkout for purchasing or payment access.
  • Authentication for the sign-in service.
  • Background jobs when delayed processing affects customers.

Keep technical detail private

A public component can summarize several checks without exposing monitored URLs, internal IDs, check configuration or diagnostic evidence. Keep internal target labels and investigation detail in the authenticated dashboard.

Represent uncertainty honestly

A component can be operational, degraded or unavailable based on its monitored evidence. Maintenance mode is a communication state for planned work, not proof that all underlying systems are healthy.

Review the public view

Open the public status page after changing components and confirm that the title, descriptions, current state and incident history make sense to someone who does not know your internal architecture.