# monitor.status-page

The banner at the top of a status page: one overall state, a headline, and
the components that are not operational. Each component's state comes from
`monitor.component-state` (Atlassian Statuspage's vocabulary).

## Worst wins

major-outage > partial-outage > degraded > maintenance > operational

| state | headline |
| --- | --- |
| `major-outage` | Major outage |
| `partial-outage` | Partial outage |
| `degraded` | Degraded performance |
| `maintenance` | Scheduled maintenance |
| `operational` | All systems operational |

Maintenance ranks below every real problem: a component that is degraded
while another is under planned maintenance is the news. It still ranks above
operational, and a component under maintenance is listed in `affected`, so
readers know it may be unavailable.

`affected` is in input order (the order the page lists its components), not
sorted by severity, so it matches the page.

## Decisions

- **No components is an error**, not "All systems operational": a page with
  nothing on it is a configuration mistake, and claiming all is well would
  hide it.
- **Names must be unique and non-empty.** Duplicates would make `affected`
  ambiguous. Names are compared exactly, so `api` and `API` are different.
- States use the registry's kebab-case (`major-outage`); Statuspage's API
  spelling (`major_outage`) is refused rather than guessed at.

## Errors

- `components must not be empty`
- `component name must not be empty`
- `duplicate component name: X`
- `unknown component state: X`

## Sources

- Atlassian Support, "Show service status with components":
  https://support.atlassian.com/statuspage/docs/show-service-status-with-components/
- Statuspage Status API, page status and component statuses:
  https://metastatuspage.com/api. Statuspage's own overall indicator is
  `none | minor | major | critical`; this capability reports the worst
  component state instead, which says more and maps onto it directly.