Show service status with components

One of the first things you’ll want to do when setting up your page is figure out which individual services or features you want to show the status of. We call these components in Statuspage, and they’re a core part of the product.

You can think of components as the individual parts of your infrastructure that your users depend on, or the functioning pieces or features of your application/service (your website, API, mobile app, etc).

Watch this video to learn more about using components in Statuspage.

Components have their own status, and they can be updated during the incident creation process or independently.

Component statuses:

  • Operational

  • Partial outage

  • Degraded performance

  • Major outage

  • Under maintenance

Component management

Choosing your components

As a new Statuspage user, you might be wondering which components you want to include on your page. To determine that, ask yourself which areas of your product your users depend on most. Which features or services that you offer have had outages or performance issues in the past? You may want to add those features or services as components on your Statuspage. Reference the examples above for some inspiration.

Organizing components

Components can have two levels of hierarchy using component groups. A component group can house multiple components within it and can be expanded to see a detailed view of the individual components.

Setting component descriptions

Components aren’t very useful if your users don’t understand what they are. For more complex components, you might want to add short descriptions to provide more context. These descriptions appear when a user scrolls over the “?” icon on each component.

How are components updated?

Components can be updated manually in the manage portal, or automatically using an integration, the API, or email automation. The most common method of updating component statuses is by creating an incident, and changing the status of the affected components during the incident creation workflow. This way, you always have an incident to provide more context on the component status change. Components can be updated without incidents too.

Third-party components

Third-party components allow you to surface the system status of other products and services on your own status page. Third-party components are updated automatically on your page when the status changes on the owner’s page. Their status can be overridden at any time.

Component subscriptions & notifications

Component status changes do not trigger notifications. Only incidents trigger subscriber notifications. With component subscriptions, your users can subscriber to incident notifications that affect certain components. This is a great way to introduce more granular and segmented incident communication, allowing your users to cut back on noise from some incidents, and only receive the notifications they care about.

Still need help?

The Atlassian Community is here for you.