Functional Weave
Code in Python

monitor.uptime-bars

One bar per UTC day for a status page's uptime history: seconds in each state, uptime and a colour state, oldest first.

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

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

What it does

The row of daily bars under each component on a status page ("90 days ago ... today"): one `DayBar` per UTC day, oldest first, each with the seconds up, degraded, down and unknown, the day's uptime in basis points and a state to colour it by.

Each day is measured by `monitor.uptime` over that day's window, with the same `maxGapSeconds` rule: a check's status holds until the next check, for at most `maxGapSeconds`, and the latest check before midnight carries into the day. So an outage that crosses midnight shows on both days.

For example

  • uptime_bars(checks ×1, 1,728,003,600, 3, 259,200) → ×3 three days of up: two full days and today up to now
  • uptime_bars(checks ×5, 1,728,007,200, 3, 86,400) → ×3 an hour down shows an outage bar at 95.83%, a slow hour a degraded bar at 100%
  • uptime_bars(, 1,728,000,100, 2, 60) → ×2 days with no checks are no-data bars, not operational ones

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 uptime_bars(checks: Sequence[Check], now: int, days: int, max_gap_seconds: int) -> List[DayBar]
checksCheck[]in strictly ascending time order
nowintUnix seconds; today's bar ends here, not at midnight
daysinthow many UTC days ending with today, 1 to 366 (90 is the usual status page)
max_gap_secondsinthow long one check's status is trusted before time counts as unknown, as in monitor.uptime
returnsDayBar[]oldest day first

The types it declares, generated into your project

BarState = Literal["operational", "degraded", "outage", "no-data"]

@dataclass(frozen=True)
class DayBar:
    """One UTC day of a status page's uptime history."""

    date: str
    #: null when nothing that day is known
    uptime_basis_points: Optional[int]
    up_seconds: int
    degraded_seconds: int
    down_seconds: int
    unknown_seconds: int
    #: outage if any down second, else degraded if any degraded, else operational; no-data when nothing is known
    state: BarState

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

from fune.monitor.uptime_bars import uptime_bars  # monitor.uptime-bars@^1
impl/python.py · 48 lines · open · raw

Imports name this capability’s declared dependencies, which fune builds next to it in your project; each one links to its page.

from typing import List, Sequence

from .monitor_check_status import Check  ← from monitor.check-status ^1.0.0 · built alongside by fune
from .monitor_uptime import uptime  ← from monitor.uptime ^1.0.0 · built alongside by fune
from .time_unix_to_iso import unix_to_iso  ← from time.unix-to-iso ^1.0.0 · built alongside by fune
from .monitor_uptime_bars_types import BarState, DayBar

_DAY = 86400


def _whole(value: object) -> bool:
    return isinstance(value, int) and not isinstance(value, bool)


def uptime_bars(checks: Sequence[Check], now: int, days: int, max_gap_seconds: int) -> List[DayBar]:
    """The last `days` UTC days ending with today, oldest first, each measured
    by monitor.uptime. Today's bar ends at `now`, so it never shows the rest
    of today as unknown."""
    if not _whole(now):
        raise ValueError("now must be whole seconds")
    if not _whole(days) or days < 1 or days > 366:
        raise ValueError("days must be 1 to 366, received %s" % (days,))
    # Floored, not truncated: before 1970 today starts on the earlier midnight.
    today_start = now - now % _DAY
    bars: List[DayBar] = []
    for i in range(days - 1, -1, -1):
        start = today_start - i * _DAY
        end = now if i == 0 else start + _DAY
        r = uptime(checks, start, end, max_gap_seconds)
        state: BarState
        if r.uptime_basis_points is None:
            state = "no-data"
        elif r.down_seconds > 0:
            state = "outage"
        elif r.degraded_seconds > 0:
            state = "degraded"
        else:
            state = "operational"
        bars.append(DayBar(
            date=unix_to_iso(start)[:10],
            uptime_basis_points=r.uptime_basis_points,
            up_seconds=r.up_seconds,
            degraded_seconds=r.degraded_seconds,
            down_seconds=r.down_seconds,
            unknown_seconds=r.unknown_seconds,
            state=state,
        ))
    return bars

Install

fune build

With that line in your source, in a Python project (language python in fune.project), fune build resolves it and its 3 dependencies, 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.uptime-bars
Download for Python monitor.uptime-bars-1.0.0-python.fune · 12,829 bytes sha256 d2b8b147d4ecdc86ef4c686d5ca0c04b40df9558feb8d9f2d7d46848d59a128e

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

The whole function, every language, is one file too: monitor.uptime-bars-1.0.0.fune, 17,393 bytes, sha256 acd1ac7feb44a8df71bcace52d4de9ffefbaaa76498627388340399962540227. 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.uptime-bars

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

# fune: after monitor.uptime-bars

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.check-status in monitor.uptime-bars
# fune: replace monitor.uptime in monitor.uptime-bars
# fune: replace time.unix-to-iso in monitor.uptime-bars

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.uptime-bars --steps.

# fune: step monitor.uptime-bars 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
three days of up: two full days and today up to now checks ×1, 1,728,003,600, 3, 259,200 → ×3
an hour down shows an outage bar at 95.83%, a slow hour a degraded bar at 100% checks ×5, 1,728,007,200, 3, 86,400 → ×3
days with no checks are no-data bars, not operational ones , 1,728,000,100, 2, 60 → ×2
at exactly midnight today's bar is empty and no-data checks ×1, 1,728,000,000, 2, 86,400 → ×2
one day: a check from before midnight carries into today checks ×2, 1,728,000,120, 1, 300 → ×1
unknown time alone does not make a bar degraded checks ×1, 1,728,001,000, 1, 600 → ×1
before 1970 the day is floored, so today starts at the earlier midnight checks ×1, -1, 2, 200,000 → ×2
down outranks degraded on the same day; uptime floors 2/3 to 6666 checks ×3, 1,728,000,300, 1, 100 → ×1
checks after now are ignored checks ×2, 1,728,000,100, 1, 1,000 → ×1
a down check at 23:59:59 marks only that day checks ×2, 1,728,000,010, 2, 60 → ×2
Show the other 7 tests
CaseArgumentsExpected
zero days is an error , 1,728,000,000, 0, 60 → error: days must be 1 to 366, received 0
more than 366 days is an error , 1,728,000,000, 367, 60 → error: days must be 1 to 366, received 367
a fractional day count is an error , 1,728,000,000, 1.5, 60 → error: days must be 1 to 366, received 1.5
a fractional now is an error , 0.5, 1, 60 → error: now must be whole seconds
a maxGapSeconds of zero is an error , 1,728,000,000, 1, 0 → error: maxGapSeconds must be a whole number of at least 1, received 0
misordered checks are an error checks ×2, 1,728,000,010, 1, 60 → error: checks must be in strictly ascending time order: 1727999995 follows 1728000000
an unknown status is an error checks ×1, 1,728,000,010, 1, 60 → error: unknown check status: offline

More from the author

## Days

- Days are UTC calendar days, `date` is `YYYY-MM-DD`. Status pages that show local days shift `now` first. - The last bar is today, and it ends at `now`, not midnight, so the part of today that has not happened yet is not reported as unknown. At exactly midnight today's bar is empty (`no-data`). - Midnight is found by flooring, so a `now` before 1970 still lands on the right day (`-1` is 1969-12-31). - Checks after `now` are ignored. - `days` is 1 to 366; 90 is the usual status page.

## State

In order: `no-data` when nothing that day is known; `outage` if any second was down; `degraded` if any second was degraded; otherwise `operational`. Unknown time alone does not change the colour of a day that has some known time: a monitor gap is not an outage. The worst moment decides, the way status pages colour their bars; the uptime figure says how bad the day was.

## Errors

- `now must be whole seconds` - `days must be 1 to 366, received X` - Everything `monitor.uptime` refuses: `maxGapSeconds must be a whole number of at least 1`, `checks must be in strictly ascending time order`, `unknown check status: X`.

Files

PathBytes
README.md1,701
impl/python.py1,761
impl/rust.rs2,745
impl/typescript.ts1,628
vectors.json5,686