# 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.