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
Each public component represents one monitored target and summarizes the checks for that target. The component name comes from the target label, so choose a customer-safe label. The public page does not expose the monitored URL, internal IDs, check configuration or diagnostic evidence.
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.