Understanding Components

Components represent the parts of your service that customers may depend on, such as your website, API, app, dashboard, or support portal.

Your status page is structured using components. They should be named and organised in a way that makes sense to your customers, so they can quickly understand which parts of your service are working normally and which parts may be affected by an incident or maintenance.

How components work

Components can be added at the top level of your status page or nested underneath another component as a sub-component.

For example, a simple status page might use top-level components like this:

Website
API
Support Portal

A more detailed setup might use sub-components to group related parts of a service:

API
   REST API
   Webhooks
   Authentication

This helps customers subscribe to the parts of your service they care about, rather than receiving updates for everything.

Choosing good component names

Use names your customers will recognise. A component should usually describe a service, product area, feature, or system that customers depend on.

Good component names include:

Website
Customer Dashboard
Mobile App
API
Billing
Support Portal

Try to avoid internal team names, technical labels, or infrastructure names unless your customers would understand them.

For example, instead of:

EU-WEB-01
Internal Services
Platform Layer

Use clearer names like:

Website
Customer Dashboard
Hosting Platform

When to use sub-components

Sub-components are useful when one part of your service contains several smaller areas that customers may want to follow separately.

For example:

Customer Dashboard
   Login
   Reporting
   Billing

Or:

API
   REST API
   Webhooks
   Authentication

Use sub-components when the extra detail helps your customers. If the structure becomes too detailed, your status page may become harder to understand.

Components and notices

Notices should always have an affected component. This helps customers understand which part of your service is affected and ensures subscribers are notified through their chosen notification channel.

For example, if you create an incident affecting your API, you would select the API component as the affected component.

Component states

Components can have three states:

• Operational
• Degraded
• Under Maintenance

Component states are driven by notices.

For example:

• When you create an incident and choose an affected component, that component's state changes to Degraded.
• When you create a maintenance notice for a component, that component's state changes to Under Maintenance.
• Once the notice is resolved or completed, the component returns to Operational.