# monitor.uptime
Uptime over a window, weighted by time, from a target's stored checks
(`monitor.check-status`'s `Check`). Returns the seconds spent up, degraded,
down and unknown, the uptime in basis points (9999 = 99.99%), and how many
checks (and down checks) ran inside the window.
## How time is assigned
Each check's status holds from its `at` until the next check, but for at most
`maxGapSeconds`. Whatever is left of a longer gap is **unknown**: a monitor
that stopped reporting has not proved the target was up. Set `maxGapSeconds`
to a little more than the check interval (two intervals is common).
- The latest check before `from` carries into the window, with the same cap,
so a window does not start with a hole just because no check landed exactly
on its first second. It is not counted in `checks`.
- Time before any check is unknown.
- The window is half-open, `from <= t < to`; a check exactly at `to` belongs
to the next window.
- `upSeconds + degradedSeconds + downSeconds + unknownSeconds` is always
`to - from`.
## The uptime figure
`uptimeBasisPoints = floor((up + degraded) * 10000 / (up + degraded + down))`.
- Degraded counts as up: the target was serving, slowly.
- Unknown time is left out of both sides rather than guessed.
- Floored, so it never reads 100.00% while any second was down (99,999 up
seconds and 1 down second is 9999, not 10000).
- `null` when nothing in the window is known.
- Computed exactly (BigInt in TypeScript, i128 in Rust), so long windows do
not lose precision past 2^53.
`checks` and `downChecks` are the event counts an event-based SLO wants
(`monitor.error-budget`, `monitor.burn-rate`); the seconds are the time-based
view.
## Errors
- `from and to must be whole seconds`
- `from must not be after to: A > B`
- `maxGapSeconds must be a whole number of at least 1, received X`
- `checks must be in strictly ascending time order: A follows B` (checked over
the whole list, not just the window)
- `unknown check status: X`