Functional Weave
Code in Python

monitor.status-page

The overall state, headline and affected components at the top of a status page, from each component's state.

1.0.0 · published 2026-10-03 by charlie · Anterra

Pinned by 14 tests, run in TypeScript, Python and Rust.

What it does

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

For example

  • status_page(components ×2) → state operational, headline All systems operational, affected every component operational is all systems operational
  • status_page(components ×2) → state degraded, headline Degraded performance, affected Search one degraded component makes the page degraded and names it
  • status_page(components ×3) → state partial-outage, headline Partial outage, affected Search, API a partial outage beats degraded; affected keeps input order

The function

The same function in TypeScript, Python and Rust, pinned by the same tests. Pick your language; the choice follows you around the registry.

def status_page(components: Sequence[Component]) -> StatusSummary
componentsComponent[]every component on the page, at least one, names unique
returnsStatusSummary

The types it declares, generated into your project

@dataclass(frozen=True)
class Component:
    """One row of a status page."""

    name: str
    state: ComponentState

@dataclass(frozen=True)
class StatusSummary:
    """The banner at the top of the page."""

    #: the worst component state
    state: ComponentState
    #: "All systems operational", "Degraded performance", "Partial outage", "Major outage" or "Scheduled maintenance"
    headline: str
    #: names of the components not operational, in input order
    affected: List[str]

Your code names it in one line, in the file that uses it

from fune.monitor.status_page import status_page  # monitor.status-page@^1
impl/python.py · 37 lines · open · raw
from typing import List, Sequence, Set

from .monitor_status_page_types import Component, StatusSummary

# Worst last. Maintenance ranks below every real problem: an outage elsewhere
# during planned work is still the headline.
_RANK = ["operational", "maintenance", "degraded", "partial-outage", "major-outage"]
_HEADLINE = {
    "operational": "All systems operational",
    "maintenance": "Scheduled maintenance",
    "degraded": "Degraded performance",
    "partial-outage": "Partial outage",
    "major-outage": "Major outage",
}


def status_page(components: Sequence[Component]) -> StatusSummary:
    """The banner for a whole status page: the worst component state wins."""
    if len(components) == 0:
        raise ValueError("components must not be empty")
    seen: Set[str] = set()
    worst = 0
    affected: List[str] = []
    for c in components:
        if c.name == "":
            raise ValueError("component name must not be empty")
        if c.name in seen:
            raise ValueError("duplicate component name: %s" % (c.name,))
        seen.add(c.name)
        if c.state not in _RANK:
            raise ValueError("unknown component state: %s" % (c.state,))
        rank = _RANK.index(c.state)
        worst = max(worst, rank)
        if rank > 0:
            affected.append(c.name)
    state = _RANK[worst]
    return StatusSummary(state=state, headline=_HEADLINE[state], affected=affected)

Install

fune build

With that line in your source, in a Python project (language python in fune.project), fune build resolves it and its 1 dependency, pins them in fune.lock, downloads only the Python package of each, and builds the code above into your project’s .fune/build, one readable file per capability with a header linking back here. Or pin a range in fune.project and build in one step:

fune add monitor.status-page
Download for Python monitor.status-page-1.0.0-python.fune · 9,321 bytes sha256 a14a314ca5fbb95a4ca7762dd3c176575610a680e54e40c48db90a149c63ff09

The manifest, vectors and README with only the Python implementation. Install it without the registry with fune add ./monitor.status-page-1.0.0-python.fune, or fetch it from a terminal with fune pull monitor.status-page@1.0.0:python.

The whole function, every language, is one file too: monitor.status-page-1.0.0.fune, 13,298 bytes, sha256 d9db4b93cf50e564dd970817a68ff904dff2740c164187a2bb320660670351ae. It installs into a project of any language.

Customise it in your app

The seams this capability offers. Put a marker directly above a function of your own and fune build wires it into the built code; the package on the registry is not changed, the built file’s header lists it under CUSTOMISED, and fune hooks lists every hook in the project. How hooks work.

before — your function gets the arguments and returns them, changed or not, or throws to refuse the call.

# fune: before monitor.status-page

after — your function gets the result and the arguments, and returns the final result.

# fune: after monitor.status-page

replace — inside this capability’s code only, calls to a dependency go to your function, with the same signature. Other capabilities that use it are unaffected; write in * to replace it everywhere.

# fune: replace monitor.component-state in monitor.status-page

step — your function runs at a numbered point inside the function’s body, receives the in-scope values it names as parameters, and may return replacements. List the points with fune show monitor.status-page --steps.

# fune: step monitor.status-page after <n|label>

Tests

A version published now needs at least 8 tests for every function, and one that expects the error for each function that throws; the registry refuses it otherwise. fune verify --all runs each case in TypeScript, Python and Rust, and a project runs them again with fune verify. This page lists the cases; it does not run them. The exact JSON is vectors.json.

CaseArgumentsExpected
every component operational is all systems operational components ×2 → state operational, headline All systems operational, affected
one degraded component makes the page degraded and names it components ×2 → state degraded, headline Degraded performance, affected Search
a partial outage beats degraded; affected keeps input order components ×3 → state partial-outage, headline Partial outage, affected Search, API
a major outage beats everything components ×3 → state major-outage, headline Major outage, affected API, Database, Docs
maintenance alone is the headline and the component is affected components ×2 → state maintenance, headline Scheduled maintenance, affected Billing
degraded outranks maintenance, a naive enum order gets this wrong components ×2 → state degraded, headline Degraded performance, affected Billing, API
a single operational component components ×1 → state operational, headline All systems operational, affected
a single component in major outage components ×1 → state major-outage, headline Major outage, affected API
names differing only in case are different components components ×2 → state degraded, headline Degraded performance, affected API
a page with no components is an error → error: components must not be empty
Show the other 4 tests
CaseArgumentsExpected
a duplicate name is an error components ×2 → error: duplicate component name: API
an empty name is an error components ×1 → error: component name must not be empty
an unknown state is an error components ×1 → error: unknown component state: down
Statuspage's snake_case spelling is not accepted components ×1 → error: unknown component state: major_outage

More from the author

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.

Files

PathBytes
README.md1,977
impl/python.py1,419
impl/rust.rs2,282
impl/typescript.ts1,489
vectors.json3,076