Components and groups

Choose which monitors your users see, and organise them into groups that make sense to them.

A component is a monitor exposed publicly under a name your users understand. A group collects related components under a heading.

Naming

The component name is the public label. Name it for what the user does, not for what you run.

If a user cannot tell whether a component’s outage affects them, the name is wrong.

Groups

Each group has a name, a set of monitors, and a sort order. Typical shapes:

• By product area — Web app, API, Integrations
• By region — Europe, North America, Asia-Pacific
• By audience — Customer-facing, Developer platform

Groups are worth adding once you have more than about six components. Below that they add ceremony without helping.

Ordering

Put the components most users care about first. The overall banner tells people whether something is wrong; the top of the list should tell them whether it is the thing they use.

What to leave off

Every component you add is a public statement about your architecture, and one more thing to explain when it goes red.

Leave off internal-only dependencies, staging, anything with a monitor that flaps, and anything whose failure a customer would never notice. Those still belong in Glowo — just on the dashboard, not the status page.

Overriding status during an incident

Component status normally follows the monitor. During an incident you can set it explicitly, because the human picture is often more accurate than the probe’s.

A monitor that checks one health endpoint may stay green while a feature behind it is broken for everyone. Setting PARTIAL_OUTAGE says what your users are actually experiencing.