Browse the docs

Components and groups

The rows on your page: naming, grouping, ordering, manual status and uptime.

On this page
  1. Choosing components
  2. Add and edit
  3. Groups
  4. Status
  5. Uptime
  6. API

Components are what customers actually read on a status page. Choosing them well is most of the work of a good page; everything else is mechanics.

Choosing components

  • Name them by what customers do, not by what you run: “Checkout”, “Sign in”, “API”, “Email notifications”. Nobody outside your team knows what orders-svc is.
  • Fewer is better. A page with four honest rows beats one with twenty that are always green.
  • Match them to what you can monitor. A component nobody updates is a component that lies.

Add and edit

On the page detail, Components lists every row. Add component asks for a name and an optional description that shows under the name on the public page. Each row's menu lets you rename, move it into a group, link a monitor, hide its uptime strip or delete it.

Order is the order customers see. Drag rows to reorder; groups reorder the same way.

Groups

Groups are headings that collect related components: “Application”, “API”, “Infrastructure”. They exist for readability only and carry no status of their own. A group can be collapsed by default on the public page, which is useful for a long list of regional endpoints. Deleting a group keeps its components and makes them ungrouped.

Status

Each component has one of five statuses. The page's overall status is the worst of its components.

StatusMeaningOverrides
OperationalWorking as expected.
DegradedWorking, but slower or with errors for some.
Partial outageDown for some customers or some functions.
OutageDown.
MaintenancePlanned work in progress.Set automatically by a running maintenance window.

Status changes in three ways, and they can disagree:

  1. By hand. Pick a status from the row's control. It is audited and takes effect on the public page within seconds.
  2. By an incident. When you report an incident you can set a status override per affected component. Resolving the incident clears it.
  3. By a monitor rule. A linked monitor going down sets the status the rule specifies, and going up restores Operational only if the component still holds the status the rule set. A manual change in between wins.
Changing a component's status does not notify subscribers by itself. Notifications go out with incident updates and maintenance events. If customers need to hear about it, report an incident.

Uptime

Every component keeps a daily record of seconds spent operational, degraded, down and in maintenance. The public page draws it as the uptime strip, and the dashboard's overview averages it. The window shown is the page's uptime history setting, up to the plan's limit. Maintenance time is excluded from the percentage.

Turn off Show uptime on a component whose history would mislead, for example one that was created last week or one that is only ever changed by hand.

API

Components and groups are managed under /user/components. Status changes use PATCH /user/components/:id/status; reordering takes a whole position map in one call. See Components in the API reference.