Services and components

A status page begins with an understandable service boundary. The Service Owner records the service name, its criticality and its current state, then names the person responsible for it. A customer-facing component can represent the portion of that service people need to recognize. Its display order helps the team present components consistently. The link back to the service lets an incident coordinator find the operational owner when a visible component changes.

The service record also anchors incidents, changes, requests and problem investigations. When a storage service is affected, the team can inspect those records together rather than relying on similar names typed into separate lists. Agree on service names before the first incident. A renamed component should still lead to the same service owner and operating record.

• Service ownership. A named person owns the service and its criticality.
• Component status. Each visible component has a service link, display order and current status.
• Operational context. Incidents and planned work refer to the service they affect.

Decide which services customers should recognize, which components belong under each service, and who may change a visible status. Set a review rhythm for retired services so an old component does not appear to describe current availability. Agree what Operational, Degraded, partial outage, major outage and Maintenance mean to the team. A component state should describe the observed service condition, while the incident holds investigation detail.

Choose how monitoring signals reach the team and who checks them before updating a component. External monitoring is a connection to configure. The service owner should be able to explain why a component is in its present state from a linked incident or scheduled change, even when a status change was entered manually.

Suppose the customer portal becomes slow while the underlying service is still active. The incident coordinator opens an incident for the affected service, assigns an investigator and identifies the affected asset. The service owner changes the customer portal component to Degraded after checking the reported behavior. The communications reviewer can then prepare an incident-linked public message. A reader sees a clear component condition while the operations team keeps the richer investigation in the incident record.

When the issue is resolved, the coordinator records the resolution and the service owner checks whether the component can return to Operational. The visible status and the incident history should tell the same story. If another component of the service remains affected, leave that component in its appropriate state and explain the difference in the next update.

• Component status board — Review each component’s current state and service link.
• Active services — Find the operating service and its owner.
• Degraded components — Focus the next status review on affected components.

Follow an interruption through incident response and prepare the public status cycle. Set the service and component ownership in implementation.